JMS 게시 구독 모델을 사용하는 애플리케이션을 작성하려고합니다. 그러나 나는 좌절에 빠졌고 게시자가 주제에서 메시지를 삭제할 수 있기를 원합니다. 유스 케이스는 내가 영구 가입자가 있고 활성 가입자가 메시지를 받게되지만 (거의 즉각적이기 때문에) 비활성 가입자가 있고 게시자가 메시지가 잘못되었다고 판단하면 메시지를 삭제할 수 있도록하고 싶습니다. 구독자가 활성화되면 더 이상 수신하지 않습니다. 문제는 이것이 어떻게 / 가능한지 모르겠다는 것입니다. 공급자의 경우 glassfish의 구현을 결정했지만 다른 대안이이 기능을 제공하는 경우 전환 할 수 있습니다.
감사합니다.
JMS는 비동기 메시징의 한 형태이므로 게시자와 구독자는 설계 상 분리됩니다. 이것은 당신이 요구하는 것을 할 메커니즘이 없다는 것을 의미합니다. 게시 시점에 활성 상태 인 구독자의 경우 조치를 취할 시간 내에 삭제 메시지를받을 기회없이 메시지를 소비합니다. 구독자가 오프라인이면 비동기 메시지는 원 자성이어야합니다. 다른 응답자의 답변 디자인을 진행하면 (삭제 메시지를 생성하고 삭제 메시지를 찾기 위해 전체 대기열을 읽으려면 소비자를 다시 연결해야 함) 가입자 여부에 따라 시스템 동작이 다른 상황이 생성됩니다. 특정 메시지 / 삭제 조합이 게시되었을 때 온라인 상태 였거나 그렇지 않았습니다. 게시자가 삭제 메시지를 보내기 직전에 구독자가 보유 된 메시지 읽기를 완료하는 경쟁 조건도 있습니다. 즉, 이러한 조건을 조정하고 경쟁 조건을 조정하기 위해 구독자에게 중요한 논리를 입력해야합니다.
이를 수행하는 데 허용되는 방법은 "보상 거래"라고하는 것입니다. 생산자와 소비자가 단일 작업 단위를 공유하지 않거나 공통 상태를 공유하지 않는 시스템 (예 : 동일한 DB를 사용하여 상태 저장)에서 이전 트랜잭션을 취소하거나 수정하려면 첫 번째 트랜잭션을 되 돌리는 두 번째 트랜잭션이 필요합니다. 물론 소비자는 보상 거래를 올바르게 적용 할 수 있어야합니다. 이 패턴을 사용하면 메시지가 실시간으로 사용되는지 아니면 소비자가 다시 시작된 후 일괄 처리로 사용되는지에 관계없이 모든 구독자가 동일한 동작을 나타냅니다.
보상 트랜잭션은 "삭제 메시지"와 다릅니다. 다른 응답자의 답변에서 제안 된 삭제 메시지는 메시지 스트림 자체에 영향을 미치는 명령 및 제어의 한 형태입니다. 반면에 보상 트랜잭션은 시스템 상태의 트랜잭션 업데이트를 통해 시스템 상태에 영향을줍니다.
일반적 으로 명령 및 제어 기능으로 메시지 스트림을 조작하여 시스템 상태를 관리하고 싶지는 않습니다 . 이는 취약하고 공격에 취약하며 감사 또는 디버그가 매우 어렵습니다. 대신 서비스 품질 제약 조건에 따라 모든 메시지를 전달하고 모든 메시지를 처리하도록 시스템을 설계하십시오. 애플리케이션에서 전적으로 상태 변경 (이전 작업 취소 포함)을 처리합니다.
예를 들어, 거래가 초과 인출 수수료와 같은 2 차 효과를 유발하는 은행에서 일반적인 절차는 하루 동안 거래를 "메모 게시"한 다음 은행이 폐쇄 된 후 일괄 적으로 정렬하고 적용하는 것입니다. 이를 통해 초과 인출 수수료가 발생 하기 전에 실수를 조정할 수 있습니다 . 최근에는 거래가 실시간으로 적용되지만 당일 장부가 마감 될 때까지 트리거가 보류되어 동일한 결과를 얻습니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다