Sql server 2008 서비스 중개자 수백만 개의 대기열

Question

우리 응용 프로그램의 새로운 기능에 대한 와이어 프레임 작업 중입니다. 요구 사항 중 하나는 각 사용자가 처리 할 항목 목록을 갖고 있다는 것입니다.

SQL Server 2008 서비스 브로커를 사용하여 할 일 목록에 대한 알림을 사용자에게 보내려합니다.

그러나 브로커 큐가 작동하는 방식으로 단일 큐의 사용자에 대한 메시지를 격리 할 수 ​​없습니다. 나는 메시지가 검색된 후에 만 ​​볼 수있다. 그러나, 나는 단지 그것을 호출하는 사용자에 대한 메시지를 검색하고 싶습니다.

그래서 브로커 서비스를 사용하려면 각 사용자마다 별도의 대기열이 필요합니다.

그러면 중개인 서비스에 수백만 개의 대기열이 생깁니다.

하나의 대기열을 가질 수 있지만 필터가있는 메시지를 검색 할 수있는 브로커 서비스의 기능이 누락 되었습니까?

SQL Server 2008 중개 서비스가 수백만 개의 큐를 처리 할 수 ​​있습니까?

Answer 1

일반적으로 메시징 응용 프로그램은 이벤트 구동 형입니다. 메시지가 오면 메시지를 처리하는 처리 절차를 활성화합니다. Service Broker는 대기열에 연결된 활성화 메커니즘을 통해이 기능을 구현합니다. 이 철학에서 메시지를 필터링 할 필요가 없습니다. 처리가 항상 대기열의 '다음 메시지'를 처리하고 대기열이 이상적으로 항상 비어 있기 때문입니다. 따라서 RECEIVE verb는 필터를 제공하지 않습니다. RECEIVE의 WHERE 절은 대화 및 대화 그룹으로 제한되며 이는 특정 메시지를 필터링하지 않고 응용 프로그램이 conversation group locking 개념을 활용하는 데 도움이되는 수단입니다.

큐은 수백만에게 좋은 생각이 필요 할 것이라고 암시 일부 수하물 운반 멋진 이름으로 위장 보통의 (내부) 테이블에 지나지 없지만 :

• 각 큐는 적어도 서비스와 관련이 있어야합니다을 그것. 서비스는 메시지 라우팅과 연결되어 시작 시간 (db를 검색하고 숨겨진 인스턴스 tempdb 테이블 만들기), tempdb 공간 (상기 라우팅 테이블) 및 런타임 메모리를 사용하므로 런타임 비용이 약간 더 비쌉니다 (라우팅과 관련된 캐시 된 메모리 구조). 또한 라우팅 알고리즘이 수백만 개의 후보를 결정할 때 CPU 오버 헤드를 유발합니다.
• 대기열이 활성화되어있는 경우 대기열이 '자체적으로'더 무거워 질 수 있습니다. 각 큐에는 메모리 및 CPU를 사용하는 런타임 모니터 인 큐 모니터가 있습니다. http://rusanu.com/2008/08/03/understanding-queue-monitors
• 대기열에 도달하려면 최소한 하나의 대화가 필요하며 라이브, 활성 대화는 약간의 오버 헤드가 발생할 수 있습니다.
• 큐 개체는 RECEIVE 동사와 연결되어 있으며 더 중요한 것은 WAITFOR(RECEIVE)입니다. WAITFOR은 서버의 작업자 스레드를 차단하므로 각 큐에 WAITFOR을 배치하기 오래 전에 sp_configure 'max worker threads'이 부족합니다.

큐/서비스는 일반 테이블보다 구성/모니터링 요구 사항에서 좀 더 '활성'상태입니다. 내가 이것을 말할 때 염두에 두어야 할 두 가지 문제점이 있습니다. poison message detection은 대기열을 트리거 및 비활성화 할 수 있습니다. 수백만 대기열에주의를 기울이지 않아도됩니다 (자동화 할 수 있고 그래야하지만 여전히 그렇습니다).어떤 이유로 든 메시지가 transmission queue을 통해 지연되는 경우 두 번째 문제가 발생할 수 있습니다. 수백만 번의 대화가 재개되어 전송이 다시 시작될 때 매우 나쁜 동작을 할 수 있습니다 (변경 사항은 다양 할 수 있으며 사용중인 SQL 버전/SP 수준에 따라 크게 달라질 수 있음). 일부 문제는 SQL 2K5 SP3 이후에 수정 됨).

Service Broker는 주로 분산 응용 프로그램의 문제 (DCM/COM +, Corba, Remoting 등의 문제를 해결하기위한 문제)를 염두에두고 고안되었습니다. 그러나 큐에 넣기 동작과 활성화 메커니즘을 활용하기 위해 종종 하나의 SQL Server 인스턴스 또는 데이터베이스 내에 완전히 포함되어 로컬로 배포됩니다. SSB를보고있는 유일한 이유가 대기열을 활용하는 것이라면 SSB 대기열과 사용자 대기열을 사용하는 대기열을 50/50으로 분할하는 것입니다. (즉, 사용자 테이블 백업 대기열과 함께 발생하는 많은 교착 상태 문제를 해결하는 방법을 알고 있습니다.) Activation을 활용한다면 SSB는 훨씬 더 매력적입니다. 실제로 원격 메시징을하는 경우 분명히 최상의 옵션입니다.

귀하의 경우, 내가 왜 대기열을 가지고 있는지 나쁜 아이디어인지 분명히하기를 바랍니다. 메시지는 어디서 발생 했습니까 (로컬 대 원격)? Service Broker를 시작하는 이유는 무엇입니까? 모든 세부 사항을 알고 있다면 가장 좋은 대안은 하나의 대기열, 도착한 모든 메시지를 처리하는 활성화 된 절차 및 각 사용자에 대한 적절한 정보를 적절하게 필터링 할 수있는 일반 테이블에 보관하는 것입니다. 각 사용자는 자신의 데이터를 찾습니다.

공개 : 나는 같은 큐에 여러 청취자 할 일 대기열을 설정하는 방법이있는 Service Broker team and maintain the SSB blog

Answer 2

의 전 멤버입니다. 서비스 브로커 대화를 추적하려면 보조 테이블이 필요하며 RECEIVE 절에 제한된 필터 기능 (대화 핸들 또는 대화 그룹 별)이 있다는 사실을 이용합니다.

테이블 수신기 만들기 (ListenerCode의 VARCHAR를 (10) 기본 키, ConversationGroup 고유 식별자 기본 NEWID())

이 표는 각 청취자에 대한 행이 있습니다. 청취자 코드 또는 다른 키는 각 청취자의 ID/코드입니다. 청취자에게 메시지를 보내야 할 때 대화 그룹을 검색하여 해당 대화 그룹을 보냅니다. 이것은 BEGIN DIALOG ... RELATED_CONVERSATION_GROUP = ....에 지정되어 있습니다.

ConversationGroup은 대화에 넣을 수있는 태그이며 참조 테이블을 가지고 있지 않습니다. (http://msdn.microsoft.com/en-us/library/ms166131.aspx 참조)

청취자는 대화 처리를 검색하여 해당 대화 그룹에서 수신합니다. 듣지 않으면 메시지가 대기열에 들어갑니다.

일단 소비되면 데이터베이스에서 메시지가 사라집니다. 이것이 사용자를 위해 처리해야 할 것들의리스트라면, 아마도 영속적 인 목록을 원할 것입니다. 그래서 나는 아마도 Task 테이블을 생성 할 것이고 큐에있는 메시지는 Task 테이블에 대한 참조가 될 것입니다. 큐는 저장소 자체가 아닌 새로운 아이템에 대한 알림 일뿐입니다.