2009-11-30 8 views
1

저는 멀티 스레드 프로그래밍에있어 매우 익숙합니다.C# - 대기열 및 다중 스레드

  • 지속적으로 데이터베이스 읽는 Windows 서비스 만들기 테이블의 항목에 대한 (또는 메시지 큐 였을를, 가장 좋은 것입니다 무엇을 제안 해주십시오) : 다음은 내가 달성하기 위해 노력하고 있습니다 것입니다.
  • 새 항목이있는 경우 테이블에 새 항목에 대한 봐가
  • , 스레드 풀에 충분한 스레드가 (아니 그게 어떻게 작동하는지 확인)가있는 경우, 확인 새 스레드를 시작하고 일부 작업을 수행 작업. 트래픽이 많은 동안 새로운 항목이 여러 개있어 멀티 스레딩해야하는 이유가 있습니다.

감사합니다. 아이디어와 링크를 도와주세요. 도와 주셔서 감사합니다.

+0

데이터베이스 테이블 대신 메시지 큐를 사용하는 경우 큐 메시지가 '새 항목'으로 간주하거나 원하는 메시지에 포함될 특정 값입니까? –

+0

대기열 메시지가 새 항목이됩니다. 또한 성공적으로 처리 된 경우 새 항목이 메시지 대기열에서 삭제됩니다. – Emon

답변

2

가능하면 데이터베이스 수정시 신호를 보내도록하는 것이 좋습니다. 연속 읽기는 거꾸로 된 디자인처럼 보입니다. 자체 서비스를 만들고 싶지 않은 경우 Windows 스케줄링 서비스를 사용하여 응용 프로그램을 시작하여 데이터베이스를 읽을 수 있습니다. ThreadPool을 사용하여 동시 작업 수를 제한 할 수는 없습니다. 그러나 자신 만의 서비스를 만드는 경우 ThreadPool 클래스를 사용하는 것은 간단합니다. 스레드 제한을 설정하고 queuing 작업 항목을 데이터베이스 업데이트를 기반으로 유지할 수 있습니다. 또한 SetMinThreads을 가지고 놀고, 스레드를 활성화하고 재사용 가능하게 유지하십시오.

0

SQL Server를 사용하는 경우 SqlCacheDependency Class을 사용하여 데이터베이스 변경 내용을 모니터링 할 수 있습니다.

1

모두 당신이 ThreadPool과 MSMQ (VB.NET 기사에 대한 링크를 용서하십시오)입니다; 아주 사소한. 귀하의 예에서 작성한 것은 대기열이 아니라 폴링입니다.

1

어디에서이 테이블을 업데이트합니까? 그 이유는 무엇입니까?

2 개의 응용 프로그램간에 '통신'하는 방법으로이 표를 사용하는 경우 MSMQ와 같은 EMS 시스템을 사용하는 것이 좋습니다. 2 개의 응용 프로그램간에 서로 대화하고 MSMQ와 함께 제공되는 모든 guareteed 전송 기능을 사용할 수 있습니다. 또한 WCF로 구워지며 쉽게 통합 할 수 있습니다.

테이블을 다른 용도로 업데이트하는 경우 (예 : 자체 대기열 시스템을 구축하지 않으려는 경우) Rashmi와 SqlCacheDepdency 권장 사항에 동의합니다. 기본적으로 .NET 코드를 SQL에 연결하여 테이블의 새 레코드가 추가되거나 기존 레코드가 업데이트 될 때 이벤트가 발생하도록 할 수 있습니다.

0

다른 사람들이 말했듯이 MSMQ를 사용하는 것이 가장 좋을 것입니다. WCF를 사용하여 서비스를 작성하고 IIS에 배포하는 것이 좋습니다. 정확하게 쉬운 것은 아니지만 Microsoft는 이미하고 싶은 일을 이미 많이 수행했습니다.

톰 홀랜더는 MSMQ, WCF 설정에 대한 기사의 큰 시리즈를 가지고 있으며 여기에 IIS : 나는 Windows 서비스의 정확하게 이런 종류의 코딩 한

http://blogs.msdn.com/tomholl/archive/2008/07/12/msmq-wcf-and-iis-getting-them-to-play-nice-part-1.aspx

1

, 나는 당신이에 있다고 생각 오른쪽 트랙.필자는 대기열에 데이터베이스 테이블을 사용합니다.이 큐는 시스템 충돌시 영구 대기열을 제공하고 로컬 네트워크에서 여러 작성자를 허용하며 트랜잭션을 통해 경합을 관리 할 수있게합니다.

각 프로세스마다 별도의 스레드를 만들고 활성 스레드의 수를 추적하여 즉석에서 조정할 수 있습니다. 각 스레드가 웹 서비스 호출을하기 때문에 스레드 풀을 사용하면 별 도움이되지 않으며 외부 서버에서 대기하는 것을 차단 한 이후 많은 스레드를 시작할 수있었습니다.

리더를 하나만 허용하면 관리하기 쉽습니다. 따라서 ID 열을 사용하고 마지막 열보다 높은 다음 큐를 선택하여 읽은 큐 항목을 추적 할 수 있습니다. 스레드가 완료되면 작업중인 항목을 삭제할 수 있습니다. 서비스가 충돌하는 경우 읽지 않은 첫 번째 항목이 표시됩니다. 항목을 터치 한 시점을 나타내는 열을 포함 시키면 더 좋아질 수 있습니다. 처리가 실패한 경우 (네트워크 시간 초과로 인한 것일 수도 있습니다), 장치를 언 터치하여 다음 읽음으로 인해 잡힐 수 있습니다. 독자가 여러 명일 필요가있는 경우 터치 한 시간을 나타내는 시간 소인 필드를 사용하십시오. 한 명의 독자가 항목을 건드린 시점을 확인하여 다른 추락 한 리더를 복구 할 수 있습니다.

동시에 처리를 완료 할 수 있도록 서비스 닫기 이벤트를 트랩해야하며 동시에 여러 기록기를 얻은 후에 일어나는 일을 추적 할 수 있도록 자체 로깅을 포함해야합니다.

대기열 리더를 망치로 잡아 당겨로드 상태를 측정 할 수있는 테스트 버전을 고려해보십시오. 이렇게하면 멀티 스레드 응용 프로그램에 숨어있는 잘 알려지지 않은 잡기를 제거하는 데 도움이됩니다.

그러나 나는 이것을 만들어내는 폭발이 있었고, 당신도 그렇게되기를 바랍니다.