Mediator가없는 ZeroMQ Pub-Sub + Dynamic Discovery

Question

중간 시스템의 경우 ZeroMQ를 Pub-Sub (서비스 버스 스타일) 인프라로 테스트하고 있습니다. 약 50 개의 노드가 있고 모두 게시자와 구독자 여야합니다. 네트워크는 별 모양의 토폴로지이지만 가장자리는 서로 "대화"합니다. 동적 검색 (참여자의 네트워크 주소를 하드 코딩 할 필요 없음)과 SPOF (Single Point of Failure)가 필요합니다.

나는 http://zeromq.org/whitepapers:0mq-3-0-pubsub을 읽었으며 동적 탐색을 위해 제안 된 0MQ 방법은 구독 및 게시를 전달하는 프록시 노드 (XPUB/XSUB)와 관련됩니다. (A) 프록시 노드가 SPOF - 전체 시스템이 작동하지 않을 때 (B) 프록시 노드가 시스템에서 중앙 중개자로 사용한다고 생각했지만이 아키텍처에 대해 다음과 같은 우려가 있습니다. 데이터를 포함한 모든 트래픽은 프록시 노드를 통과하므로 대기 시간이 &이고 성능 문제가 발생합니다.

pub-sub 백서를 올바르게 이해했다고 가정하면 ZeroMQ에서 pub-sub + dynamic-discovery + no-SPOF를 달성하는 비교적 간단한 방법이 있습니까?

추가 요점 : 대부분의 메시지에는 관심이있는 단원이 하나 많지 않으므로 멀티 캐스트 (PGM) 솔루션이 제외되었으므로 네트워크가 과밀 사용되는 것을 원하지 않습니다.

Answer 1

구독자가 게시자와 직접 대화 할 수 있으므로 단일 게시자가있는 여러 구독자는 중개가 필요하지 않습니다. 하지만 동시에 많은 게시자와 구독자가 그렇게 쉽지는 않습니다. 중간에 무언가가 없으면 새 구독자가 기존의 모든 게시자와 구성되어야하므로 관리가 악몽이 될 수 있습니다.

각각 자신의 컴퓨터에 여러 개의 XSUB/XPUB 프록시를 배치 한 다음 게시자와 프록시간에로드 밸런서 (예 : F5)를 배포 할 수 있습니다. 이를 통해 업스트림 측에서로드 균형 조정 및 내결함성을 달성 할 수 있습니다.

프록시 코드는 간단하다 : 프록시 노드에 오류가 발생

Socket frontend = context.socket(ZMQ.XSUB); 
frontend.bind("tcp://proxy1:5444"); 
Socket backend = context.socket(ZMQ.XPUB); 
backend.bind("tcp://proxy1:5555"); 
frontend.subscribe("".getBytes()); 
ZMQ.proxy (frontend, backend, null); 

, 그냥 다시 시작; re-connections/subscription은 zmq에 의해 자동으로 처리되어야합니다. 다운 스트림 가입자

가능한 모든 프록시에 직접 각 가입자를 연결합니다

subscriber = ctx.createSocket(ZMQ.SUB) 
subscriber.connect("tcp://proxy1:5555") 
subscriber.connect("tcp://proxy2:5555") 
subscriber.connect("tcp://proxy3:5555") 

와서 그렇게 프록시 수 있기 때문에 적은 구성 유지 보수 프록시 결과에 직접 가입자를 연결, 프록시보다 더 자주 갈 것

게시자 대부분 정적 일 것입니다.

프록시 노드가 실패하면 업스트림 LTM은 나머지 프록시 노드에 따라 트래픽을 라우팅합니다. 구독자는 사용 가능한 모든 프록시에서 소비하므로 영향을받지 않습니다.

느린 가입자는 동기화를 통해 해결 될 수 있으며 this에 있습니다.
구독 동의를 확인하고 네트워크 트래픽을 최소화하십시오 here.