Эта серия представляет собой краткий обзор книги «RabbitMQ в действии: эффективное развертывание распределенных очередей сообщений».
Из введения первых двух статей я узнал об основных элементах и процессе взаимодействия при обмене сообщениями, а также о том, как запускать RabbitMQ и управлять им.Эта статья позволит понять преимущества «общения, ориентированного на сообщения» с точки зрения разработки. режиме и в различных сценариях. Рекомендации ниже.
Через введение вы узнаете:
- Преимущества обмена сообщениями
- Забыть модель
- Реализация RPC с RabbitMQ
Преимущества коммуникации, ориентированной на сообщения
В основном с точки зрения асинхронного мышления о состоянии, масштабируемости возможностей обработки и сложности интеграции объясняются преимущества коммуникации, ориентированной на сообщения.
Асинхронное мышление
При интеграции обмена сообщениями в приложение модель разработки изменится с синхронной модели на асинхронную модель, RabbitMQ предлагает другой подход, который позволяет нам отправлять запросы в одном месте и обрабатывать их в другом, так что синхронная программа может продолжать работу. выполнять другую логику.
Вот простой пример для иллюстрации через кредитную карту Alipay:
- Пользователь вводит номер кредитной карты, банк-эмитент, имя держателя карты, сумму погашения и отправляет заявление на погашение;
- Alipay сразу подскажет пользователю, что заявка отправлена и сколько часов будет завершено погашение;
- После завершения погашения пользователю будет отправлено сообщение, чтобы напомнить, успешно ли погашение;
Если это синхронный запрос, пользователь должен ждать несколько часов, чтобы просмотреть результат, и другие операции не могут быть выполнены в процессе ожидания, что очень неразумно.
Асинхронное мышление состоит в том, чтобы разделить запрос и обработку и использовать RabbitMQ в середине двух тесно связанных частей приложения.После анализа запроса сообщение, которое может понять бизнес, отправляется в RabbitMQ, и оно возвращается в реальная обработка выполняется асинхронно другой службой.
Расширяемость
С расширением бизнеса спрос на услуги, увеличивающие вычислительную мощность, RabbitMQ может просто увеличить вычислительную мощность.
Поскольку RabbitMQ может равномерно распределять запросы между обрабатывающими серверами, нет необходимости в балансировщике нагрузки.
API с нулевой стоимостью
Чтобы вызывать друг друга между системами, необходимо согласовать набор API.Вообще говоря, требуется немного времени, чтобы написать большой кусок кода для преобразования входящих HTTP-запросов в вызовы функций в приложении.
Если AMQP используется для подключения различных частей приложения, нет необходимости определять дополнительные API, достаточно использовать обмен сообщениями. Кроме того, AMQP не зависит от языка и имеет привязку к родному языку для десятков языков.
Забыть модель
При рассмотрении проблемы, которую могут решить сообщения, основные области передачи сообщений относятся к режиму обработки «пост-эмиссии». Какая забота, что задание будет выполнено, а завершать не обязательно, создайте задание, после отправки на свитч можно вернуться для продолжения, или даже уведомив пользователя о выполнении задания.
Два типа задач, которые соответствуют этому шаблону:
- Пакетная обработка: для работы или преобразования больших наборов данных несколько задач обрабатывают независимые части набора данных;
- Уведомление: описание отправленного события, которое может быть журналом сообщений или уведомлением для другой программы или администратора;
Примеры, представленные в книге, относительно просты, поэтому они здесь не приводятся, в основном для определения типа и ключа маршрутизации коммутатора в соответствии с различными сценариями.Для понимания можно обратиться к примеру «сбора логов», приведенному в предыдущей статье. .
Реализация RPC с RabbitMQ
Существует много способов реализации удаленного вызова процедур RPC, таких как REST API, SOAP, Thrift и т. д. Эти традиционные методы реализации RPC имеют нечто общее: клиент и сервер тесно связаны между собой, и им приходится ждать возврата результата. . Также рассмотрите эти вопросы:
- Когда есть несколько сервисных узлов, клиент, как найти соответствующий сервер;
- Если сервер RPC, к которому подключен клиент, выходит из строя, клиенту требуется дополнительная логика для повторного подключения;
При реализации через сервер MQ он просто публикует сообщение, направляет сообщение в соответствующее место и загружает сообщение через несколько серверов RPC.Когда сервер, обрабатывающий сообщение, дает сбой, сообщение RPC повторно отправляется в другую башню.
Теперь вопрос в том, что если ответ будет возвращен клиенту?
RabbitMQ использует сообщения для отправки ответов. В заголовке сообщения AMQP есть поле, называемое reply_to. Создатель сообщения может использовать это поле, чтобы определить имя очереди и прослушивать очередь, чтобы дождаться ответа. Получатель сообщения может проверьте поле reply_to и создайте ответ, содержащий содержимое нового сообщения, с именем очереди в качестве ключа маршрутизации.
Что касается имени очереди reply_to, если производитель объявляет очередь без имени, RabbitMQ автоматически сгенерирует уникальное имя очереди и укажет эксклюзивный параметр при его объявлении, чтобы гарантировать, что только производитель, создавший очередь, может читать сообщения в очереди. .
Таким образом, все, что нужно сделать RPC-клиенту, — это объявить временную эксклюзивную анонимную очередь и включить имя очереди в заголовок reply_to сообщения RPC, чтобы сервер знал, куда отправить ответное сообщение.
Многие сцены, использующие «Отправь как в ближайшее время забудь», те, кому не нуждаются в ответе лечения, если требуется ответ, вы можете использовать RABRITMQ RPC модель.
В следующей статье будут рассмотрены кластеризация и высокая доступность RabbitMQ, а также их настройка.
Добро пожаловать, чтобы отсканировать QR-код ниже и подписаться на мою личную общедоступную учетную запись WeChat ~