하늘색 서비스 버스 대기열의 NServiceBus pub-sub

Question

Azure Service Bus가 뒷받침하는 NServiceBus을 사용하여 간단한 pub-sub 데모를 구현하려고합니다.

다양한 조건에 따라 더 많은 스폰 된 구독자 또는 기존 구독자가 삭제되므로 구독자를 만들 때마다 고유 한 이름을 사용하여 Endpoint 및 EndpointInstance을 만들고 관심있는 이벤트

구독자가 종료되면 이벤트 수신을 거부하고 EndpointInstance을 중지하십시오.

그러나 서비스 버스를 확인하면 프로세스에서 생성 된 대기열 및 주제 가입이 정리되지 않습니다. 이것은 잠시 후에 내가 EndpointInstance 이름을 생성하는 방식으로 인해 다시는 사용되지 않을 수백 개의 대기열과 주제 서브 스크립 션을 가질 수 있음을 의미합니다.

어떻게 정리하나요?

내가 누락 된 항목이 있습니까? 모든 가입자에 대해 새로운 Endpoint 및 EndpointInstance을 생성하지 않아야합니다 (공식 샘플 및 가이드에 사용 된 패턴 인 것 같습니다).

UPDATE : 고객 (가입자) 온라인 버스에 가입 푸시 알림 시스템과 같은

단지 마음에 온 비유 뭔가. 이벤트가 게시되면 나는 모든 온라인 클라이언트가 그것을 받기를 원합니다. 클라이언트가 종료되면 클라이언트가 온라인 상태가되면 메시지를 잃어 버리는 것에 관심이 없기 때문에 보내지는 메시지는 신경 쓰지 않습니다. 구독을 닫고 기본 인프라 (대기열, 구독 등)를 정리하고 싶습니다.

내 시나리오에서 각 클라이언트는 고유 한 종점 및 종단점 인스턴스를 정의합니다. 이 시점에서 논리적 종단점은 어떻게 작동합니까?

Answer 1

게시판/서브 데모과 엔드 포인트가 삭제 된 후 모든 것을 정리할 수있는 기능이 있습니다. 엔드 포인트를 적절하게 구독 취소하면 Azure Service Bus에서 구독이 제거되고 게시 된 메시지가 더 이상 대기열에 도착하지 않습니다.

프로덕션 시나리오에서 다양한 이유로 엔드 포인트를 가져올 수 있습니다. 그 중 하나는 데이터 저장소에 새 버전을 배포하거나 유지 관리를 수행하는 것입니다. 또 다른 하나는 서버/서비스 충돌 등의 간단한 작업 일 수 있습니다. 생산 시나리오에서는 메시지가 여전히 대기열에 도착하기를 원할 것입니다. 이렇게하면 엔드 포인트가 다시 백업 될 때마다이를 안정적으로 처리 할 수 ​​있습니다.

이 때문에 우리는 대기열 정리를 지원하지 않습니다. 엔드 포인트를 종료 한 후 모든 것을 정리하려면 큐를 수동으로 제거해야하며 그렇지 않은 경우는 수동으로 제거해야합니다.

데모 설정 정보는 고유 한 종점과 인스턴스를 언급합니다. 명확성을 위해 엔드 포인트와 인스턴스의 의미를 설명하도록하겠습니다. 몇 가지 작업을 수행하는 논리적 끝점을 만들 수 있습니다. 이것은 다양한 핸들러, 사가 등을 포함 할 수 있습니다. 고유 한 이름과 고유 한 기능을 가지고 있습니다. 시스템에 다양한 논리적 끝점을 가질 수 있습니다.

배포시 일반적으로 모든 끝점에 대해 하나의 인스턴스가 있습니다. 수평 확장을 원할 경우 동일한 논리적 끝점의 다른 인스턴스를 배포 할 수 있습니다.Azure Service Bus를 사용하는 경우 competing consumers이라는 것이 있습니다. 기본적으로 두 엔드 포인트 인스턴스가 동일한 큐에서 메시지를 검색하려고합니다. 하나는 항상 이기고 메시지 처리를 시작합니다.

메시지를 수신 할 (논리적 인) 엔드 포인트의 인스턴스를 절대로 알 수 없기 때문에 동일한 엔드 포인트의 다른 인스턴스에 메시지를 공개하는 것은 논리적이지 않습니다. 여전히 자신의 메시지를 구독 할 수 있지만 논리적 끝점은 자체 메시지를 구독합니다. 특정 인스턴스에 대해서는이 작업을 수행하지 마십시오. 불가능합니다.

그러나 은이지만 다른 논리적 끝점에서 수신 한 메시지는 게시 할 수 없습니다. 그들이 얼마나 많은 경우가 있더라도 상관 없습니다. 나 퍼즐 이제 어떻게

---

당신의 다음 진술 :

내가 가입자의 예측할 수 함께 일하고 이상이 양산되고하거나 기존의 다양한 조건에 따라 죽는와

즉석에서 새로운 논리적 끝점을 만들고이를 배치하는 것처럼 보입니다. 은으로 배포시 구성에 따라 고유 한 이름을 지정할 수 있습니다. 그러나 나는 왜 당신이 이것을 데모하고 싶은지 이해하지 못합니다.

이 정보가 도움이되는지 알려주세요. 그렇지 않은 경우이 게시물 아래에 댓글을 달아 주시면 더 많은 질문에 답변 해 드리겠습니다. 아마도이 게시물에 업데이트로, 주석의 수가 문자의 수에 제한되어 있기 때문에 사용할 수 있습니다.

Answer 2

설명 된 시나리오가 의미가 있습니다. 작성된 임시 엔드 포인트에 관심이 있으며 목적을 달성 한 다음 시스템에서 제거됩니다. 이러한 끝점은 고유하며 여러 인스턴스가 없습니다. 그리고 그들이 그렇게하더라도, 모든 경우가 알려집니다.

즉, 잠시 후 내 EndpointInstance 이름을 생성하는 방식으로 인해 다시는 사용되지 않을 수백 개의 대기열과 주제 구독이있을 것입니다.

구독으로 인해 발생하는 문제는 버그입니다. 나는 문제를 제기했습니다 here: link. 더 많은 피드백을 제공하려면 부탁하십시오. 예상되는 동작은 버그가 해결되면 이 일 수 있습니다. 나는. 특정 이벤트의 구독을 취소하면 더 이상 해당 이벤트를 끝점 (ForwardingTopology의 경우)으로 전달하거나 끝점의 구독 (EndpointOrientedTopology의 경우)에 저장하지 않아야합니다.

엔드 포인트 입력 대기열의 경우 NSB가 엔드 포인트 자체가 실행중인 동안 대기열을 제거 할 수있는 방법이 없습니다. 끝점을 찍은 후 사용자 지정 코드 에 대한 내용입니다.

Answer 3

여기에 어떤 종류의 가입자가 있습니까? 모든 클라이언트가 동일한 유형의 이벤트를 수신해야합니까 아니면 필터링하려고합니까? 그것의 마지막 경우 더 통지처럼.

잠시 동안 귀하의 시스템에 연결하는 클라이언트가 있고이 클라이언트 전용 이벤트에만 관심이있는 것으로 생각됩니다.

SignalR과 같은 프레임 워크는 특정 클라이언트에 알림을 다시 보내려는 경우에 적합합니다.

그러나 시스템 내에서 NServiceBus를 사용하여 올바른 클라이언트에 알림으로 푸시되어야하는 이벤트를 트리거 할 수있는 자체 엔드 포인트 사이에서 통신 할 수 있습니다.