Ваши вопросы действительно затрагивают суть теории очередей и процессов, поэтому я отвечу с этой точки зрения (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
