나는 토끼 mq를 조종하고있어 매우 좋습니다. HA 페이지를 보면 exchange/queue replication이 잘 작동하는 것을 알 수 있습니다.RabbitMQ 클라이언트로드 밸런싱
사실 TCP로드 밸런서를 사용하여 노드 간의로드 밸런스를 조정해야한다는 것이 문제가됩니다. 이 올바른지?
"replicate-all"정책을 가진 클러스터에 2 개의 노드를 갖고 싶습니다.
모든 노드에 라운드 로빈과 비슷한 동작으로 연결할 수 있기를 원하는 퍼블리셔 또는 소비자가 필요합니다. 아쉽게도 클라이언트 API는 연결 당 하나의 호스트 만 설정할 수 있습니다.
게시자가 퍼블리시하고 소비자가 모든 노드에서 사용하도록 솔루션 (예 : 타사 어쩌면?)과 같은 풀이 있습니까?
AMQP/RabbitMQ에 대한 연결 풀링을 수행하는 클라이언트를 보지 못했습니다. AMQP는 채널이있는 단일 프로세스에서 여러 게시자/고객을 처리하며 일부 클라이언트는이를 사용하기 쉽지만 연결 풀을 사용하여 노드의 자동 장애 조치를 처리하지는 않습니다.
클러스터에서는 클러스터의 모든 노드에 연결할 필요가 없으므로 게시 작업이 올바르게 클러스터 내에서 라우팅됩니다. 여러 구독으로 하나 또는 여러 개의 프로세스를 관리하는 데 소비하는 경우 (각 연결마다 적어도 하나는 소비)가 절대로 내게 최우선 순위가 아니 었습니다. RabbitMQ에 무작위로 연결되는 여러 프로세스를 사용하면 RabbitMQ 노드 중 하나가 실패 할 경우 가용성을 유지할 수 있습니다.
수명이 긴 연결의 게시자는 장애가 감지되어 문제가 발생하지 않을 경우 문제가 발생하지 않을 경우 쉽게 다시 연결할 수 있습니다.
몇 년 동안 사용 해본 결과 새 호스트에 다시 연결하는 것이 기존 AMQP 연결과 관련하여 응용 프로그램 내에서 상태를 관리한다는 어려운 문제로 인해 장애 조치 (failover) 중에 더 간단한 문제라고 말합니다. 실제로 나는 사용할 수있는 호스트 목록을 유지하고 새로운 연결마다 다음 호스트를 선택했습니다. 연결이 닫히면 언제든지 새 호스트를 선택하고 다시 시도하십시오. 짧은 시간에 게시 할 수 없으며 PHP에서 지속적으로 새로운 연결을 만들어야하는 경우 더 어려울 수도 있습니다.
flow control으로 인해 TCP 부하 분산기가 더 큰 문제가 될 수 있습니다. TCP 백 프레셔 (back pressure)는 출판사가 RabbitMQ가 처리 할 수있는 것보다 빨리 게시하도록 LB를 통해 이루어지지 않을 수도 있습니다. 비 과학적 테스트에서 클라이언트가 직접 연결되어있을 때로드 밸런서 뒤에있을 때 RabbitMQ 안정성에 더 많은 문제가있었습니다.
당신은 어떤 종류의 클라이언트를 사용하는지 언급하지 않았지만 파이썬에는 훌륭한 Kombu 라이브러리가 있습니다. Kombu는 connection and producer pools을 모두 지원합니다.
round-robbin, shuffle 또는 사용자 지정 장애 조치 전략이 적용된 여러 AMQP 서버를 지정할 수도 있습니다. when settting up a connection.
python nameko의 경우, HA (Rabbitmq)를 달성하기위한 제안 된 방법은 here이다. 나도 팽나무 버섯은 혹시 해결책을 마련 했 round-robin failover
AMQP_URI: pyamqp://guest:[email protected]:5672/;pyamqp://guest:[email protected]:5672/
을 지원하는 백업 라이브러리 (다시마)로 이것을 달성하기 위해 관리? –
관련 - http://stackoverflow.com/a/32478091/830964. –