2011-09-20 4 views
2

특정 응용 프로그램에서 서비스 '명단'에 대한 권장 사항에 대한 피드백을 얻으려고합니다. 클라이언트와 지속적인 소켓 연결을 유지하는 서버 응용 프로그램이 있습니다. 분산 된 인스턴스를 지원하기 위해 서버를 추가로 개발하고 싶습니다. 서버 "A"는 다른 온라인 서버 인스턴스에 데이터를 브로드 캐스트 할 수 있어야합니다. 다른 모든 활성 인스턴스에도 동일하게 적용됩니다. 각 서버 인스턴스가 구성 서버에 자신을 등록 할 것, 그리고 그것을 변경으로 연결된 모든 서버 구성 업데이트를받을 - 분산 서버 인스턴스 간의 데이터 브로드 캐스트

  1. 가 레디 스/사육사/Doozer가 :

    옵션은 내가 연구에 노력하고 있습니다. 그 때 무엇?

    1. 각 서버 인스턴스와 엔드 - 투 - 엔드 연결을 유지하고 각 보내는 데이터로 목록을 반복합니다.
    2. 사용자 지정 UDP 멀티 캐스트가 있지만 그 위에 안정성을 추가해야합니다.
  2. 사용자 지정 메시지 브로커 - 각 서버가 연결되어이를 알릴 때마다 레지스트리를 실행하고 유지 관리하는 서비스입니다. 각 서버와의 연결을 유지하여 데이터를 받아들이고 다른 서버로 다시 브로드 캐스트합니다.
  3. 일부 신뢰할 수있는 UDP 멀티 캐스트 전송으로 각 서버 인스턴스가 직접 브로드 캐스트하고 로스터가 유지되지 않습니다. 여기

내 관심사 :

  • 내가 사육사 또는 doozer 같은 외부 애플리케이션에 의존하지 않도록 싶어요하지만 난 분명히을 사용하는 것이 사용자 지정 메시지 브로커와의 최적의 솔루션
  • 경우 , 병목 현상이되기를 원하지는 않을 것입니다. 그렇다면 스케일링 할 때 여러 메시지 브로커를 실행하고로드 밸런서를 사용해야 할 수도 있습니다.
  • 내 자신을 롤업 할 경우 멀티 캐스트가 외부 프로세스를 필요로하지 않지만 그렇지 않은 경우 ZMQ를 사용해야 할 수도 있습니다. 다시 ZMQ를 사용하면 다시 상황이 달라집니다.

나는 메시지 전달에 대해서도 말하고 있지만, 나는 함께 가고있는 해결책과 관련이있다. 그건 그렇고, 내 서버는 Go로 작성되었습니다. 확장 성을 유지하는 가장 좋은 방법에 대한 아이디어가 있습니까?

*이 목표의 수정은 *

내가 정말 해달라고 부탁하는 것은 주어진 분산 서버의 인스턴스 사이에서 데이터 방송 구현하는 가장 좋은 방법은 무엇입니까는 다음

  1. 각 서버 인스턴스 유지 영구적 인 TCP 소켓 연결을 원격 클라이언트와 연결하고 그 사이에 메시지를 전달합니다.
  2. 메시지는 실행중인 다른 인스턴스로 브로드 캐스팅하여 relavant 클라이언트 연결에 전달할 수 있어야합니다.
  3. 메시징이 고속 일 수 있으므로 대기 시간이 중요합니다.
  4. 시퀀스와 안정성이 중요합니다.

* 업데이트 질문 요약

여러 서버 서로간에 술집/하위 필요/복수의 끝 지점이있는 경우는, 그들 사이의 의사 소통의 권장 모드는 무엇입니까 *? 검색된 서버의 명부에 메시지를 다시 게시하는 하나 이상의 메시지 브로커? 각 서버에서 직접 신뢰할 수있는 멀티 캐스트가 가능합니까? 대기 시간을 낮게 유지하고 속도를 높이며 전송을 안정적으로 유지하면서 분산 시스템에서 여러 종단점을 어떻게 연결합니까?

+0

이제 Redis는 필연적으로 시스템의 일부가되어서 데이터 기록을위한 지속적인 저장소로 언급 될 수 있습니다. 따라서 서비스를 등록하고 해당 pub/sub 기능을 통해 알리는 것이 확실한 경로라고 가정합니다. – jdi

+0

대기 시간은 어떻게 되나요? – lunixbochs

+0

고속 메시지 서버이므로 대기 시간이 짧아야합니다. 메시지가 들어와 채널 구독자에게 브로드 캐스트되지만 영구적 인 소켓 서버를 사용하면 결국 파일 설명자 제한과 결국 클라이언트 포트 범위 제한이 발생합니다.따라서 여러 인스턴스를 실행해야하며 메시지가 다른 인스턴스의 대기열로 넘어 가서 해당 인스턴스의 동일한 채널에 가입 할 수있는 사람에게 배포 할 수 있어야합니다. – jdi

답변

2

모든 클라이언트 측 끝점이 동일한 LAN에 있다고 가정하면 (안정적인 첫 번째 단계 일 수 있음) 신뢰할 수있는 UDP 멀티 캐스트를 사용하면 게시 끝점에서 게시 된 끝점에 직접 게시 된 메시지를 보낼 수 있습니다. 채널에 가입 한 클라이언트가있는 엔드 포인트 이는 또한 영구 저장소 계층을 통해 데이터를 프록시하는 것보다 대기 시간이 짧은 요구 사항을 훨씬 충족시킵니다. > 채널 - (PORT IP) <

멀티 캐스트 그룹

  • 중앙 데이터베이스 (예를 들어, 레디 스)가 멀티 캐스트 그룹의지도를 추적 할 수 있습니다.
  • 엔드 포인트가 등록 할 새 채널로 새 클라이언트를 수신하면 데이터베이스에 채널의 멀티 캐스트 주소를 요청하고 멀티 캐스트 그룹에 참여할 수 있습니다.

신뢰할 수있는 UDP 멀티 캐스트

  • 엔드 포인트가 채널에 게시 된 메시지를 수신, 그 채널의 멀티 캐스트 소켓에 메시지를 보냅니다.
  • 메시지 패킷에는 멀티 캐스트 그룹당 서버별로 정렬 된 식별자가 포함됩니다. 엔드 포인트가 서버에서 이전 메시지를 수신하지 않고 메시지를 수신하면 게시 서버로 다시 보내지 않은 모든 메시지에 대해 "수신 확인되지 않음"메시지를 보냅니다.
  • 게시 서버는 최근 메시지 목록을 추적하고 NAK 된 메시지를 다시 보냅니다.
  • 하나의 메시지 만 전송하고 서버에 도달하지 못하는 서버의 엣지 경우를 처리하기 위해 서버는 NAK 대기열의 수명 동안 멀티 캐스트 그룹에 패킷 수를 보낼 수 있습니다. "나는 24 개의 메시지를 보냈습니다" 다른 서버에 이전 메시지를 NAK 할 수있는 기회를줍니다.

PGM을 구현하는 것이 좋습니다.

영구 저장

는 데이터를 장기간 저장 끝날 경우, 스토리지 서비스는 단지 엔드 포인트와 같은 멀티 캐스트 그룹에 가입 ...하지만 클라이언트로 전송하는 대신 데이터베이스에 메시지를 저장할 수 있습니다.

관련 문제