SQL Server Service Broker가없는 일반 테이블을 사용하여 이벤트가 SQL Server Azure 데이터베이스에 저장되는 분산 이벤트 기반 시스템의 참조 아키텍처를 구성하는 중입니다.데이터베이스 큐 및 큐 처리
이벤트는 새 이벤트 메시지에 대한 대기열을 폴링 할 작업자 역할을 사용하여 처리됩니다.
제 연구에서 여러 프로세서가 대기열에서 메시지를 처리 할 수있게 해주는 여러 가지 솔루션이 있습니다. 여러 가지 프로세스가 단일 메시지 대기열에 액세스하려고 시도 할 때 잠금 등을 관리하는 복잡성이 추가되는 경우가 많습니다.
전통적인 대기열 패턴은 하나의 대기열에서 여러 개의 프로세서를 가져 오는 것임을 알고 있습니다. 그러나 이벤트 메시지를 임의의 순서로 처리 할 수 있다고 가정하면 대기열과 대기열 처리기간에 일대일 관계를 작성하지 않고 다른 대기열간에로드 균형을 조정해야하는 이유가 있습니까?
queue_1 => processor_1
queue_2 => processor_2
이러한 구현은 다수의 프로세서에 걸쳐 큐에 대한 동시 액세스를 관리하는 데 필요한 모든 배관을 피할 수있다. 이벤트 게시자는 모든로드 균형 알고리즘을 사용하여 메시지를 게시 할 큐를 결정할 수 있습니다.
내 검색에서 이런 종류의 구현이 보이지 않는다는 사실 때문에이 디자인에서 큰 적자를 간과한다고 생각합니다. 이 게시물 등 내가 내구성 메시지를 포함하여 나에게 가능한 기본 대기 옵션의 숫자가 있다는 것을 이해 MSMQ, 푸른 큐, 대 대기열로 데이터베이스 테이블을 사용을 통해 논쟁을 촉발했다 편집
Azure AppFabric의 버퍼. 필자는 옵션을 평가하여 SQL Azure 테이블로 충분하다고 판단했습니다. 내 질문의 의도는 큐 당 하나의 프로세서 대 하나의 큐에 대해 여러 개의 프로세서 사용을 논의하는 것이 었습니다.
"그래서 나는 무엇을 놓치고 있습니까?" 나는 적절한 이벤트 큐를 사용하는 전체 요점을 놓치고 있다고 제안한다. 이벤트 대기열이 이미 일류 제품인 경우 데이터베이스를 사용하여 이벤트 대기열을 작성하는 것은 어리석은 것처럼 보입니다. 왜 MS-MQ를 사용하지 않고 많은 고통을 덜어 주실 수 있습니까? –
@S. Lott : 나는 항상 같은 가게에 대기열과 데이터를 보유 할 이유가 있다고 주장합니다. 모든 작업 (메시지 저장소와 데이터 저장소 간의 DTC), 배포/문제 해결/관리를위한 하나의 제품, 메시지 저장소와 데이터 저장소에서 함께 실패한 HA/DR 솔루션 1 개를 사용하여 균일 한 백업/복원, 2 단계 커밋 제거 일관성있는 상태로 유지되며이 모든 것들이 데이터베이스 내부의 대기열에 대해 매우 중요한 경우입니다. 거의 모든 메시지가 데이터 작업의 결과로 시작하고 데이터 업데이트를 끝내는 것을 고려하면 이벤트 *는 데이터이며 함께 속합니다. –
@ S.Lott : 1) Azure에 배포 할 때 MSMQ가 없습니다. 2) MS-MQ에는 많은 고통이 있습니다. –