Kolejkowanie wiadomości o niskim opóźnieniu i dużej skali

Właśnie buduję taki system.

Zrobiłem sporo oceny kilku MQs, w tym RabbitMQ, Qpid i ZeroMQ. Opóźnienia i przepustowość któregokolwiek z nich są więcej niż odpowiednie dla tego typu aplikacji. Co jednak nie jest dobre, to czas tworzenia kolejki w środku pół miliona kolejek lub więcej. W szczególności Qpid dość poważnie spada po kilku tysiącach kolejek. Aby obejść ten problem, zazwyczaj będziesz musiał stworzyć swój własny mechanizmy routingu (mniejsza liczba kolejek ogółem, a konsumenci w tych kolejkach dostają wiadomości, którymi się nie interesują).

Mój obecny system prawdopodobnie będzie używał ZeroMQ, ale w dość ograniczony sposób, wewnątrz klastra. Połączenia z klientami są obsługiwane za pomocą niestandardowej karty sim. daemon, który zbudowałem przy użyciu libev i jest całkowicie jednowątkowy (i wykazuje bardzo dobre skalowanie-powinien być w stanie obsłużyć 50 000 połączeń na jednym pudełku bez żadnych problemów-nasz sim. wskaźnik kleszczy jest jednak dość niski i nie ma fizyki).

XML (a więc XMPP) bardzo nie nadaje się do tego, ponieważ procesor będzie przetwarzał XML na długo przed tym, zanim zostaniesz związany z I / O, co nie jest tym, czego chcesz. W tej chwili używamy buforów protokołu Google, a te wydają się dobrze dopasowane do naszych szczególnych potrzeb. Korzystamy również z protokołu TCP dla połączeń klienckich. Miałem doświadczenie w używaniu zarówno UDP, jak i TCP do tego w przeszłości i jak zauważyli inni, UDP robi mieć jakąś przewagę, ale jest to nieco trudniejsze do pracy.

Mam nadzieję, że kiedy będziemy bliżej premiery, będę mógł podzielić się więcej szczegółami.

Jon, to brzmi jak idealny przypadek użycia AMQP i RabbitMQ.

Nie jestem pewien, dlaczego mówisz, że użytkownicy AMQP są dużymi korporacjami typu enterprise. Ponad połowa naszych klientów znajduje się w przestrzeni "internetowej", od wielkich po małe firmy. Z RabbitMQ powstało wiele gier, systemów bukmacherskich, systemów czatowych, systemów typu twittery oraz INFRA-cloud computing. Istnieją nawet aplikacje na telefony komórkowe. Obiegi pracy to tylko jeden z wielu przypadków użycia.

Staramy się track of what is going on here:

Http://www.rabbitmq.com/how.html (upewnij się, że przejdziesz do listy przypadków użycia na del.icio.us też!)

Proszę spojrzeć. Jesteśmy tu, aby pomóc. Napisz do nas na adres [email protected] lub uderz mnie na Twitterze (@monadic).

FWIW, dla przypadków, w których wyniki pośrednie nie są ważne (np. informacje o pozycjonowaniu) Qpid posiada "kolejkę ostatniej wartości", która może dostarczyć Subskrybentowi tylko ostatnią wartość.

Moje doświadczenie było z nie-otwartą alternatywą, BizTalk. Najbardziej bolesną lekcją, jaką wyciągnęliśmy, jest to, że te złożone systemy nie są szybkie. A jak się domyśliłeś z wymagań sprzętowych, przekłada się to bezpośrednio na znaczne koszty.

Z tego powodu, nawet nie zbliżaj się do XML dla podstawowych interfejsów. Twój klaster serwerów będzie parsował 2 miliony wiadomości na sekundę. To może być 2-20 GB / s XML! Jednak większość wiadomości będzie za kilka kolejek, podczas gdy większość kolejek jest w fakt mały ruch.

Dlatego zaprojektuj swoją architekturę tak, aby łatwo było zacząć od serwerów kolejek COTS, a następnie przenieść każdą kolejkę (typ) do niestandardowego serwera kolejek, gdy zidentyfikowane zostanie wąskie gardło.

Również, z podobnych powodów, nie zakładaj, że architektura kolejki komunikatów jest najlepsza dla wszystkich potrzeb związanych z komunikacją, jakie ma Twoja aplikacja. Weźmy przykład "lokalizacja obiektu w instancji". Jest to klasyczny przypadek, w którym nie chcesz gwarantowanego dostarczania wiadomości. Na powodem, dla którego musisz udostępnić te informacje, jest to, że zmieniają się one cały czas. Jeśli więc wiadomość zostanie utracona, nie chcesz tracić czasu na jej odzyskanie. Wyślesz tylko starą lokalizację dotkniętej istoty. Zamiast tego chcesz wysłać bieżącą lokalizację tego obiektu. Pod względem technologicznym oznacza to, że chcesz UDP, a nie TCP i Niestandardowy mechanizm odzyskiwania strat.