RabbitMQ: Wymiana, kolejki i wiązania - kto konfiguruje co?

Question

Podczas korzystania z RabbitMQ do wysyłania wiadomości zasadniczo masz wymiany, kolejki i powiązania. Rozumiem ich pomysł i sposób, w jaki się ze sobą łączą, ale nie jestem do końca pewien, kto to ustawi.

Zasadniczo mam trzy scenariusze w mojej aplikacji.

Scenariusz 1: Jeden wydawca, kilka pracownik przetwarza

Co chcę osiągnąć jest jednym z elementów, który wysyła wiadomości do kolejki, a tam będzie kilka procesów roboczych, które zajmują pozycje w tej kolejce. Wydaje mi się to dość łatwe. Konfiguracja jest następująca:

• Exchange: 1 wymiany z typu 'direct'
• kolejki: 1 kolejka
• Oprawa: Kolejka jest zobowiązany do wymiany

Gdy wiadomość jest wysłany na giełdę, zostaje dostarczony do kolejki, a procesy robocze otrzymują swoje zadania.

Wszystko będzie trwałe.

Kto więc tworzy co? Moim zdaniem:

• Producent tworzy wymiana
• Producent tworzy kolejkę (jako że obecnie może być żadnych procesów roboczych z systemem, a wiadomość zostanie utracone w inny sposób, jeśli nie było kolejka)
• Producent robi wiązania kolejki do wymiany
• konsumenci po prostu słuchać w kolejce

Prawda?

Scenariusz 2: Jeden wydawca kilku abonentów, lotne wiadomości

Drugi scenariusz jest zupełnie inna. Zasadniczo jest to scenariusz pub/sub, w którym każda wiadomość jest wysyłana do każdego aktualnie słuchającego klienta. Jeśli klient przejdzie w tryb offline, nie będzie już otrzymywać wiadomości i nie będzie dla niego przechowywany w innym miejscu. Oznacza to następujące ustawienia:

• wymiany: 1 wymiany typu „fanout”
• kolejki: n kolejki, po jednym dla każdego konsumenta
• wiążąca: Każdy warkocz musi być związane z wymianą

Więc kto co konfiguruje?Moim zdaniem:

• Producent tworzy wymiana
• Consumer tworzy kolejkę (jak to ma własną kolejkę, a producent nie może wiedzieć, kto jest zainteresowany w komunikatach)
• Consumer tworzy wiązanie jej kolejce do wymiana
• Consumer słucha swojej kolejki

prawda?

Scenariusz 3: Jeden wydawca kilku abonentów, trwałe wiadomości

zasadzie taki sam, jak scenariusz 2, ale wiadomości nie powinny zostać utracone, jeśli konsument przechodzi w tryb offline. Moim zdaniem nie powinno to niczego zmieniać - prawda?

Answer 1

myślę, co mówisz, jest w porządku z wyjątkiem scenariusza 3.

Jeśli wiadomości nie powinny zostać utracone, jeśli konsument przechodzi do trybu offline, a następnie trzeba trwałe kolejki i kolejki nie można auto_delete'd.

Wszystko inne wydaje mi się właściwe.

W przypadku scenariusza 2 można również zezwolić firmie RabbitMQ na automatyczne generowanie nazw kolejek, a następnie pozwolić na automatyczne usuwanie kolejek po rozłączeniu konsumenta.