2013-05-30 17 views
5

Pilotuję królika mq i uważam, że jest całkiem niezły. Patrząc na stronę HA stwierdzam, że replikacja wymiany/kolejki działa dobrze.Równoważenie obciążenia klienta RabbitMQ

Jestem zaniepokojony faktem, że muszę użyć równoważnika obciążenia TCP, aby zrównoważyć obciążenie między węzłami. Czy to jest poprawne?

Chciałbym mieć 2 węzły w klastrze z zasadą "replikuj wszystko".

Chciałbym i wydawcy lub konsumenta, aby móc połączyć się ze wszystkimi węzłami w sposób podobny do robota typu "round-robin". Niestety API klienta pozwala tylko na ustawienie jednego hosta na połączenie.

Czy istnieje jakieś rozwiązanie (np. Strona trzecia), które umożliwia publikowanie recenzji, a konsumenci korzystają ze wszystkich węzłów?

+0

Czy kiedykolwiek wymyślić rozwiązanie? –

+0

Powiązane - http://stackoverflow.com/a/32478091/830964. –

Odpowiedz

3

Nie widziałem żadnych klientów, którzy łączą połączenia dla AMQP/RabbitMQ. AMQP obsługuje wielu wydawców/klientów w jednym procesie z kanałami, a niektórzy klienci sprawiają, że jest to łatwe w użyciu, ale nie radzą sobie z automatycznym przełączaniem awaryjnym węzłów przy użyciu puli połączeń.

W klastrze nie ma potrzeby łączenia się ze wszystkimi węzłami w klastrze, operacje konsumowania i publikowania będą poprawnie trasowane w obrębie klastra. Za pochłonięcie próbą zarządzania jednym lub wieloma procesami z wieloma subskrypcjami (przynajmniej jednym zużyciem dla każdego połączenia) nigdy nie było dla mnie najwyższym priorytetem. Przy wielu procesach zużywających się, każdy losowo łączący się z RabbitMQ, będzie w stanie utrzymać dostępność w przypadku awarii jednego z węzłów RabbitMQ.

Wydawcy w długotrwałych połączeniach mogą z łatwością nawiązać połączenie, jeśli wykryta zostanie awaria powodująca mniej niż sekundę zakłóceń, wystarczająco mała we wszystkim, nad czym pracowałem, aby nie stanowiła problemu.

Od kilku lat użytkowania powiedziałbym, że ponowne połączenie z nowym hostem jest prostszym problemem podczas przełączania awaryjnego z trudnym problemem z zarządzaniem stanem w aplikacji w odniesieniu do istniejących połączeń AMQP. W praktyce właśnie zachowałem listę dostępnych hostów i wybrałem następną dla każdego nowego połączenia. Za każdym razem, gdy połączenie zostanie zamknięte, wystarczy wybrać nowego hosta i spróbować ponownie. To oznacza krótki czas, w którym nie można publikować i może być trudniejsze, jeśli trzeba ciągle tworzyć nowe połączenia w PHP.

Z uwagi na flow control urządzenia równoważące obciążenie TCP mogą stanowić więcej kłopotu niż są warte. Wsteczne ciśnienie TCP może nie przejść przez LB, co powoduje, że wydawcy publikują szybciej niż RabbitMQ może sobie poradzić. W nienaukowych testach miałem więcej problemów ze stabilnością RabbitMQ, gdy znajdowałem się za równoważnikiem obciążenia, a następnie, gdy klienci łączyli się bezpośrednio.

Powiązane problemy