RabbitMQ wstrzymać zużycie kolejki

Question

Jaki jest najlepszy sposób na utrzymanie trwałej kolejki i powiązań, ale zawieszenie jej klientów?

Przypadek użycia: chciałbym "pozwolić mu się zawiesić" i przestać obsługiwać wiadomości, jeśli otrzymujemy masę wiadomości, z którymi nie możemy sobie poradzić (np. Baza danych nie działa lub problem z schematem), ale chciałby dalej agreguj do kolejki. To pozwala na publikowanie, ale zawiesza konsumpcję.

mogę myśleć o trzech rozwiązań:

1. mogę mieć wszystkie urządzenia związane z kolejki ciągłego odrzucania wiadomości i ponownie kolejkę, ale jest to rodzaj zasobów odpadów nie wspominając Mam programowo zrobić powyżej logiki.
2. mogę zadzwonić basic.cancelConsumer na wszystkich konsumentów (patrz niżej)
3. albo w kategoriach spring-amqp Chyba mogę nazwać shutdown na wszystkich SimpleMessageListenerContainers, które są zobowiązane do kolejki.

już to robimy, ponieważ wiadomości są odrzucane. Problem polega na tym, że kończy się to jak nieskończoną pętlą awarii i jeśli twoje logowanie, że porażka, nawet więcej zasobów zostanie zmarnowane.

#3 wydaje się być idealnym rozwiązaniem, ale muszę wiedzieć, w jaki sposób można dowiedzieć się o wszystkich słuchaczach wiadomości, a następnie powiadomić ich o wyłączeniu. Przypuszczam, że mógłbym użyć wymiany fanoutów, aby powiadomić, że kolejka musi zostać zawieszona. Czuję, że RabbitMQ musi mieć coś wbudowanego w tę logikę. Inną kwestią jest to, że można powiązać wiele kolejek z kontenerem wiadomości (nie wszystkie zawieszenie może wymagać zawieszenia).

Dla #2 wiem mogę cancel the consumer z jego consumerTag ale pytanie (zakładając, że jest to dobry sposób, żeby zrobić to powyżej), gdzie mogę uzyskać listę consumerTag s do kolejki?

Answer 1

Jeśli chcesz zatrzymać konsumenta, po prostu zadzwoń do podstawowego anulowania, to jest sposób na zrobienie tego.

uwzględniając trwałe kolejki jest sprawą, że można rozwiązać, jeśli deklarują kolejki: durable=trueauto_delete=false.

z przetrwałym wiadomości jest określana, gdy ich rozpatrzenie: delivery_mode=2.

Każdy konsument ma swój własny znacznik konsumentów. Za każdym razem, gdy odbierzesz wiadomość z kolejki, koperta powinna mieć znacznik konsumencki i powinieneś wywołać podstawowe anulowanie z tym znacznikiem.

AFAIK, nie możesz mieć konsumenta A w połączeniu 1 i anulować podstawowe anulowanie dla tego konsumenta w innym połączeniu. Mogę się mylić w tej sprawie.

Answer 2

To rozwiązanie ma specyfikację spring-amqp. Jest to w zasadzie #3 z mojej odpowiedzi.

Utrzymuję usługę, która ma Map<String,CustomSimpleMessageListenerContainer> nazwy kolejki na niestandardową rozszerzoną SimpleMessageListenerContainer.

Po określonej liczbie wyjątków wysyłam komunikat "panika", który przechodzi do specjalnej kolejki odebranej przez usługę, aby zamknąć konsumenta.