RabbitMQ AMQP.Podstawowe cechy.Wartości konstruktora

W momencie pisania:

1. najnowszym standardem AMQP jest AMQP 1.0 OASIS Standard .
2. najnowszą wersją RabbitMQ jest 3.1.5 (serwer i klient), który twierdzi, że obsługuje AMQP 0.9.1 (Schematy pdf i XML spakowane).
3. RabbitMQ dostarcza własny opis protokołu jako schemat XML zawierający rozszerzenia (tzn. Niestandardowy), plus schemat XML bez rozszerzeń (który jest identyczny ze schematem linkowanym przez (2)) i pdf doc .

W tej odpowiedzi:

• Linki w (3) są głównym źródłem szczegółów
• (2) pdf doc jest używany jako dodatkowy szczegół, jeśli (3) jest nieodpowiedni
• Kod źródłowy (klient java, serwer erlang) jest używany jako trzeciorzędny szczegół, jeśli (2) jest nieodpowiedni.
• (1) na ogół nie jest używany - protokół i schemat zostały (dość) znacząco rozwinięte Dla / przez Oasis i powinny mieć zastosowanie do przyszłych wersji RabbitMQ, ale nie mają zastosowania teraz. The two wyjątki, w których użyto (1) dotyczyły opisów tekstowych contentType i contentEncoding - co jest bezpieczne, ponieważ są to standardowe pola z dobrymi opisami w AMQP 1.0.

Poniższy tekst jest parafrazowany z tych źródeł przeze mnie, aby uczynić go bardziej zwięzłym lub jasnym.

• content-type (AMQP XML type="shortstr"; java type="String"): opcjonalne. Typ MIME RFC-2046 dla sekcji application-data (body) wiadomości. Może zawierać parametr charset definiowanie używanego kodowania znaków: np. 'text / plain; charset= "utf-8"'. Jeśli typ zawartości jest Nieznany, nie należy ustawiać typu zawartości, umożliwiając odbiorcy określenie rzeczywistego typu. Jeśli sekcja jest znana jako prawdziwie nieprzezroczyste dane binarne, typ zawartości powinien być ustawiony na application / octet-stream.
• content-encoding (AMQP XML type = "shortstr"; java type= "String"): opcjonalne. Gdy występuje, opisuje dodatkowe kodowania treści stosowane do application-data, a więc jakie mechanizmy dekodowania należy zastosować, aby uzyskać Typ nośnika, do którego odwołuje się pole nagłówka content-type. Używany głównie w celu umożliwienia skompresowania dokumentu bez utraty tożsamości jego podstawowego typu zawartości. Modyfikator typu treści, interpretowany zgodnie z sekcją 3.5 RFC 2616. Poprawne kodowanie treści jest rejestrowane w IANA. Implementacje nie powinny używać kodowania compress, z wyjątkiem tego, aby zachować zgodność z oryginalnymi komunikatami wysyłane z innymi protokołami, np. HTTP lub SMTP. Implementacje nie powinny określać wielu wartości kodowania zawartości, z wyjątkiem tego, aby były zgodne z komunikatami pierwotnie wysłanymi z innymi protokołami, np. HTTP lub SMTP.
• headers (AMQP XML type="table"; Java type="Map"): opcjonalne. Zdefiniowana przez Aplikację Lista parametrów nagłówka i ich wartości. Mogą one być ustawione tylko do użytku aplikacji. Dodatkowo możliwe jest tworzenie kolejek z "Typu wymiany nagłówków" - gdy kolejka jest tworzona, otrzymuje szereg nazw właściwości nagłówka do dopasowania, każda z opcjonalnymi wartościami do dopasowania, tak że przekierowanie do tej kolejki odbywa się poprzez dopasowanie nagłówka.
• deliveryymode (RabbitMQ XML type = "octet"; java type= "Integer"): 1 (nietrwałe) lub 2 (trwałe). Działa tylko dla kolejek, które implementują persistence. Trwała wiadomość jest bezpiecznie przechowywana na dysku i gwarantowana do dostarczenia nawet w przypadku poważnej awarii sieci, awaria serwera, przepełnienie itp.
• priority (AMQP XML type="octet"; java type="Integer"): względny priorytet wiadomości ( 0 do 9 ). Komunikat o wysokim priorytecie to [może być?? - GB] wysyłane przed wiadomościami o niższym priorytecie czekającymi w tej samej kolejce wiadomości. Gdy wiadomości muszą zostać odrzucone w celu utrzymania określonego poziomu jakości usługi, Serwer najpierw odrzuci wiadomości o niskim priorytecie. Działa tylko dla kolejek, które implementują priorytety.
• correlation-id (AMQP XML type = "octet"; java type = "String"): opcjonalne. Do użytku aplikacji, brak formalnego (RabbitMQ) zachowania. Identyfikator specyficzny dla klienta, który może być używany do oznaczania lub identyfikacji wiadomości między klientami.
• replyTo (AMQP XML type="shortstr"; java type="String"): opcjonalne. W przypadku użycia aplikacji nie ma formalnego zachowania (RabbitMQ), ale może zawierać nazwę prywatnej kolejki odpowiedzi, gdy jest używana w wiadomościach żądania. Adres węzła do wyślij odpowiedzi do.
• expiration (AMQP XML type="shortstr"; java type="String"): opcjonalne. RabbitMQ AMQP 0.9.1 schemat z (3) stwierdza "do użytku implementacyjnego, brak formalnych zachowań". AMQP 0.9.1 schema pdf from (2) określa bezwzględny czas, kiedy ta wiadomość jest uważana za wygasłą. Jednak oba te opisy muszą być zignorowane, ponieważ ten link TTL i Kod klienta/serwera wskazują, że poniższe informacje są prawdziwe. Od klienta, wygaśnięcie jest wypełniane tylko poprzez niestandardową inicjalizację aplikacji podstawowych właściwości. Na serwerze jest to używane do określenia TTL od punktu, w którym wiadomość jest odbierana na serwerze, przed kolejką. Serwer wybiera TTL jako minimum (1) message TTL (Client BasicProperties expiration jako relatywny czas w milisekundach) oraz (2) queue TTL (configured x-message-TTL w milisekundach). Format: string quoted integer reprezentujący liczbę milisekund; czas wygaśnięcia od otrzymania wiadomości na serwerze.
• message-id (AMQP XML type="shortstr"; java type="String"): opcjonalne. Do użytku aplikacji, brak formalnego (RabbitMQ) zachowania. Jeśli jest ustawiona, producent wiadomości powinien ustawić ją na globalnie unikalną wartość. W przyszłości (AMQP 1.0) broker może odrzucić wiadomość jako DUPLIKAT, jeśli wartość message-id odpowiada wartości wcześniej otrzymanej wiadomości wysłanej do tego samego węzła.
• timestamp (AMQP XML type= "timestamp"; java type= " java.util.Data"): Opcjonalne. Do użytku aplikacji, brak formalnego (RabbitMQ) zachowania. Absolutny czas, kiedy ta wiadomość została utworzona.
• type (AMQP XML type=" shortstr"; Java type= "String"): opcjonalne. Do użytku aplikacji, brak formalnego (RabbitMQ) zachowania. [Opisuje wiadomość jako "typ", "formularz" lub "transakcję biznesową" - GB]
• userId (AMQP XML type = "shortstr"; java type = "String"): opcjonalne. XML Schema stwierdza "do użytku aplikacji, brak formalnego (RabbitMQ) zachowania" - ale wierzę, że zmieniło się to w najnowszej wersji (Czytaj dalej). Jeśli jest ustawiona, klient ustawia tę wartość jako tożsamość użytkownika odpowiedzialnego za wytworzenie wiadomości. From RabbitMQ: Jeśli ta właściwość jest ustawiona przez wydawcę, jej wartość musi być równa nazwie użytkownika użytego do otwarcia połączenia (tzn. następuje Walidacja, aby upewnić się, że jest on podłączonym/uwierzytelnionym użytkownikiem). Jeśli identyfikator użytkownika własność nie jest ustawiona, tożsamość wydawcy pozostaje prywatna.
• appId (RabbitMQ XML type="shortstr"; java type="String"): opcjonalne. Do użytku aplikacji, brak formalnego (RabbitMQ) zachowania. Identyfikator tworzenia aplikacji. Mogą być wypełniane przez producentów i odczytywane przez konsumentów. (Patrząc na kod serwera r-MQ, nie jest on w ogóle używany przez serwer, chociaż wtyczka "webmachine-wrapper" zapewnia skrypt i dopasowane szablony do tworzenia webmachine-gdzie administrator może zapewnić appId do skryptu.)
• cluster Id (RabbitMQ XML type="N/A"; java type="String"): przestarzały w AMQP 0.9.1 - tzn. nie używany. w poprzednich wersjach był identyfikatorem trasowania wewnątrz klastra, używanym przez aplikacje klastrowe, które nie powinny być używane przez aplikacje klienckie (tzn. nie wypełnione). Jest to jednak przestarzałe i usunięte z obecnego schematu i nie jest używane przez kod serwera r-MQ.

Jak widać powyżej, zdecydowana większość te właściwości nie mają wartości wyliczonych / ograniczonych / zalecanych, ponieważ są "tylko do użytku aplikacji" i nie są używane przez RabbitMQ. Więc masz łatwą pracę. Możesz swobodnie zapisywać / odczytywać wartości, które są przydatne dla Twojej aplikacji - o ile pasują do typu danych i kompilują :). ContentType i contentEncoding są zgodne ze standardowym użyciem HTTP. DeliveryMode i priority są liczbami ograniczonymi.

Uwaga: przydatne, ale proste stałe dla AMQP.Podstawowe właściwości są dostępne w klasie MessageProperties .

UPDATE TO POST:

Z podziękowaniami dla Renata (Zobacz komentarze), spojrzałem na kod serwera erlang w rabbit_amqqueue_process.erl i dokumentacja w RabbitMQ rozszerzenia TTL do AMQP . Można podać datę wygaśnięcia wiadomości (time-To-live)

• W kolejce via:

  Map<String, Object> args = new HashMap<String, Object>();
  args.put("x-message-ttl", 60000);
  channel.queueDeclare("myqueue", false, false, false, args);
  

• Lub za wiadomość przez:

  byte[] messageBodyBytes = "Hello, world!".getBytes();
  AMQP.BasicProperties properties = new AMQP.BasicProperties();
  properties.setExpiration("60000");
  channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);
  

Tutaj TTL / expiration jest w milisekach, więc 60 SEK w każdym przypadku. Zaktualizowali powyższą definicję wygaśnięcia , aby odzwierciedlić to.

Spec AMQP definiuje ogólny, rozszerzalny model właściwości.

Właściwości AMQP są w pewnym sensie podobne do nagłówków HTTP, ponieważ reprezentują metadane dotyczące danych wiadomości. Podobnie jak w HTTP, są one oprawione oddzielnie do ładunku wiadomości. Ale są one w zasadzie kluczem/wartością mapy.

Niektórzy brokerzy, tacy jak RabbitMQ, zinterpretują pewne właściwości wiadomości, takie jak expiration, aby dodać dodatkową wartość specyficzną dla dostawcy (w tym przypadku, wymuszając TTL ).

Ale w końcu, właściwości AMQP to tylko duża grupa par klucz / wartość, które są bezpiecznie wysyłane wraz z każdą wiadomością, jeśli zdecydujesz się to zrobić. Dokumentacja Twojego brokera AMQP powie Ci, które z nich interpretują specjalnie i jak wysłać własne.