Tibco EMS는 the User's Guide, this answer 및 here에 설명 된대로 서버 쪽의 핫 백업 구성에서 내결함성을 제공합니다.TIbco EMS 클라이언트 내결함성
그러나 클라이언트 측면에서 Tibco EMS는 내결함성 클라이언트를위한 즉시 사용 가능한 솔루션을 제공합니까? 예 : 주제 Sports.F1.PitStop에 두 개의 클라이언트 (server1, server2)가 게시자로 등록됩니다. 서버 1 (즉, server1의 게시자가 다운 됨)에서 문제가 발생하면 server2가 원활하게 주제에 대해 게시를 계속한다는 생각입니다. 따라서 문제는 Tibco EMS가 클라이언트 측 결함 허용 기능을 제공합니까?
번호
EMS (또는 JMS) 클라이언트 측 결함 허용 기능을 지원하지 않습니다. 그 이유는 간단합니다. 일반적으로 게시자 프로세스는 서로를 알지 못합니다.
는 정교하게하려면 :
주제는 일반적으로 많은 출판사 (두 개 이상)을 받아들입니다. 게시자/게시자 시나리오에서 게시자는 구독자를 알지 못하지만 일반적으로 다른 게시자를 알지 못합니다.
귀하의 솔루션 :
솔루션에 대한 내 첫 번째 질문 : 왜 두 서버가 동시에 메시지를 게시 할 수 없습니다를?
나는 server1과 server2의 메시지가 중복되는 것과 같은 좋은 이유가 있다고 가정합니다. 이 경우 "능동적"서버와 "수동적"서버 사이에 어떤 종류의 의사 소통이 있어야합니다.
가능성 1 : Server2는 단순한 서비스/rmi/기타 하트 비트 메커니즘에 연결되어 있으며 Server1이 게시를 중지 할 것인지 여부를 알 수 있습니다.
가능성 2 : Server2 자체가 주제에 가입되어 있으며 메시지가 중지 된시기를 알 수 있습니다.
마지막 주 : (같이 하나 개의 내구성 구독 두 서버간에 공유되는) shared "subscriptions"을 의미하는 경우 : 새로운 JMS 2.0 API는이 기능을 지원하고있다. EMS 8은 JMS 2.0을 지원하는 유일한 EMS 버전입니다.
질문을 완전히 이해할 수 있을지 잘 모르겠습니다. EMS는 메시지 브로커입니다. 그것은 메시지를 중개합니다. 그게 다 그렇습니다. 동일한 주제로 게시하는 서버가 여러 개인 경우 EMS를 사용할 수 있습니다. 게시자 자신이 장애 조치 (failover) 구성에있는 경우, 첫 번째 게시자가 적극적으로 보내고 다른 게시자가 실패하면 EMS는 상관하지 않습니다.
한 게시자에서 다른 게시자로의 장애 조치 메커니즘을 관리하는 것은 사용자가 직접 개발해야하는 것입니다. EMS는이를 지원하기위한 어떠한 것도 제공하지 않습니다. server1이 다운 된시기를 알기 위해서는 server2가 어떤 종류의 메커니즘이 필요합니다. 활성 서버가 (물론 가능한 EMS를 통해) 정기 하트 비트 메시지를 전송하고 수동 서버가 그들에게 듣고 그들이 중지 할 때, 서버 1을 가정 할 경우
중복이 이유입니다. – aateeque