Вашите въпроси наистина засягат сърцето на опашката и теорията на процесите, така че ще отговоря от тази гледна точка (RabbitMQ наистина е общ брокер на съобщения, що се отнася до моите отговори, тъй като това се отнася за всеки брокер на съобщения).
Как се обработва паралелността в метода basic.get? Извикването към метода basic.get синхронизирано ли е, за да обработва едновременни потребители, всеки от които използва своя собствена връзка и канал? C1, C2 и C3 изпращат повикване на basic.get, за да получат съобщение едновременно (да приемем, че сървърът получава всичките 3 заявки едновременно).
Отговор 1: RabbitMQ е проектиран да бъде надежден брокер на съобщения. Той съдържа вътрешни процеси и контроли, за да се гарантира, че едно и също съобщение не се предава многократно на различни потребители. Сега, поради непрактичността на тестването на сценария, който описвате, работи ли перфектно? Кой знае. Ето защо правилно проектираните приложения, използващи базирана на съобщения архитектура, ще използват идемпотентни транзакции, така че ако една и съща транзакция се обработва многократно, резултатът ще бъде същият, както ако транзакцията е била обработена веднъж. Извод: Проектирайте приложението си така, че отговорът на този въпрос да е маловажен.
C1 изисква съобщение с помощта на basic.get и получава M1. Когато C2 поиска съобщение, тъй като използва различна връзка, получава ли отново M1?
Отговор 2: Не. При спазване на предположенията от предишния ми отговор, брокерът RabbitMQ няма да върне същото съобщение, след като бъде доставено. В зависимост от настройките на канала и опашката, съобщението може да бъде автоматично потвърдено при доставка и никога няма да бъде доставено повторно. Други настройки ще имат опашката за съобщения автоматично при "смърт" на обработващата нишка/канал или отрицателно потвърждение от вашата обработваща нишка. Това е важна функционалност, тъй като едно „отровно“ съобщение може многократно да предизвика хаос във вашето приложение, ако може да бъде обслужено до множество потребители. Изводи: можете спокойно да разчитате на това предположение при проектирането на вашето приложение.
Как потребителите могат да изтеглят съобщения на партиди с предварително определен размер?
Отговор: Те не могат, нито би имало смисъл за тях. Във всяка система за опашка основното предположение е, че елементите се премахват от опашката в един файл. Опитите да се наруши това предположение водят до непредвидимо поведение; освен това потокът от една част обикновено е най-ефективният метод за обработка. В реалния свят обаче има случаи, при които са необходими партидни размери > 1. В такива случаи има смисъл да заредите пакета в собствено единично съобщение, така че това може да изисква отделна нишка за обработка, която изтегля съобщенията от опашката и ги групира заедно или първоначално ги поставя в пакети. Имайте предвид, че след като имате множество потребители, няма възможен начин да се гарантира, че отделни съобщения ще бъдат обработени по ред. За вкъщи: Пакетирането трябва да се избягва, когато е възможно, но когато не е практично да се избягва, може да не приемате, че пакетите ще съдържат отделни съобщения в определен ред.
person
theMayer
schedule
23.11.2014
