Очередь сообщений (MQ) — это метод связи (межпроцессного взаимодействия) между различными приложениями. Приложения обмениваются данными, записывая и извлекая данные (сообщения) из очереди и из очереди, не связывая их через выделенное соединение. Обмен сообщениями относится к связи между программами путем отправки данных в сообщениях, а не путем прямого вызова друг друга, что обычно используется для таких методов, как удаленный вызов процедур (RPC). Очередь относится к приложениям, взаимодействующим через очереди. Использование очередей устраняет требование одновременного выполнения принимающих и отправляющих приложений. Это естественным образом достигает цели асинхронности. Итак, каковы функциональные сценарии MQ? Следующие вводятся один за другим.

разъединение

Развязка.png

Наиболее прямой сценарий использования MQ — разделение двух систем.Например, в нашем бизнес-сценарии удержания платежей пользователь создает заказ и отправляет его обратно сразу после отправки MQ, а система расчетов использует MQ для вычета суммы учетная запись пользователя. Таким образом, система заказов должна сосредоточиться только на успешном создании заказа, максимальном увеличении объема заказа и возврате заказа пользователю сразу после создания заказа. Система расчетов фокусируется на вычете суммы счета, чтобы гарантировать, что сумма счета в конечном итоге непротиворечива. Этот сценарий также будет включать проблемы с идемпотентностью повторных попыток, которые будут представлены позже.

сбривание пиков и заполнение долин

Возьмем в качестве примера сценарий системы заказов и системы расчетов, если система заказов вызывает систему расчетов через структуру RPC, количество сгенерированных заказов будет очень большим в случае пиковых рекламных акций, а также потому, что скорость создания заказов также очень быстро, это должно произойти.Система оказывает давление на систему расчетов, и коэффициент использования сервера будет высоким.Однако, когда объем заказа относительно невелик в момент времени, который не является пиковым, использование сервера скорость расчетной системы будет низкой. Для системы расчетов появятся следующие пики и впадины.

Снятие пиков и заполнение впадин.png

Затем, если заказ хранится в очереди MQ через MQ, а потребитель использует метод вытягивания, а скорость вытягивания контролируется потребителем, поток можно контролировать для стабилизации. Таким образом, для системы расселения была достигнута цель срезания пиков и заполнения долин. Или играть в цель управления потоком. Далее мы вводим метод вытягивания.

Режим pull означает, что пользователь активно вызывает метод pull в коде, и нет необходимости настраивать в конфигурационном файле, скорость pull контролируется пользователем, и один вызов pull сообщение для потребления. Здесь мы должны обратить внимание на потребление. Если производительность потребления снизится, это обязательно вызовет отставание, поэтому пользователь включает многопоточность, чтобы контролировать степень параллелизма для повышения скорости потребления.
Пример кода:

messageConsumer.start();
for (;;){
    //手动拉取消息
    messageConsumer.pull(topic,messageListener);
}

method: pull(String topic,MessageListener listener)
тема: относится к названию темы потребления
listener: это объект обратного вызова. Когда pull извлекает сообщение, он будет активно вызывать listener.onMessage(),
Отличие от режима прослушивания заключается в том, что в режиме прослушивания поток демона клиента MQ непрерывно извлекает сообщения для потребления.В режиме извлечения пользователь управляет частотой извлечения, и сообщения не будут потребляться, если они не вызываются активно. Но не нужно активно подтверждать сообщение. Этот метод больше подходит для написания сценариев, поскольку гарантируется конечный результат, потому что чтение должно вернуться немедленно, чтобы не заставлять пользователей долго ждать и не влиять на пользовательский опыт.

возможная согласованность

конечная согласованность.png

Проблемы непротиворечивости делятся на сильную непротиворечивость, слабую непротиворечивость и возможную непротиворечивость. Большинству интернет-бизнесов требуется окончательная согласованность. Взяв в качестве примера бизнес-сценарий системы заказов и системы расчетов, после того, как система заказов успешно создает заказ, результат, возвращаемый пользователю, является успешным, и он четко сообщает пользователю, что соответствующая сумма будет вычтена из счета. . Тогда система расчетов должна поддерживать то же состояние, что и система заказов, то есть со счета пользователя фактически списывается та же сумма. Система заказов будет включать два действия: одно — создать успешный заказ, другое — отправить уведомление об успехе в MQ, мы можем поместить эти два действия в локальную транзакцию, либо успех, либо отказ. Если при отправке MQ произошел сбой один раз, это можно компенсировать в сочетании с временными задачами, которые могут гарантировать, что результат формирования заказа может быть помещен в хранилище MQ. Точно так же потребитель системы расчетов полагается на механизм повторных попыток MQ для отправки сообщений до тех пор, пока потребитель окончательно не подтвердит, что операция по вычету была успешно обработана. Таким образом, мы добавляем компенсацию через лендинг сообщений, а потребитель рассматривает гарантию повторного потребления с точки зрения бизнеса, то есть выполняются идемпотентные операции, а для достижения финальной согласованности используется MQ.

широковещательное потребление

MQ имеет два режима сообщений: один — режим «точка-точка», а другой — режим публикации/подписки (наиболее часто используемый режим). В то же время режим публикации/подписки можно разделить на кластерное потребление и широковещательное потребление в соответствии с типом потребления. Большую часть времени мы используем кластерное потребление.

Потребление кластера: MQ отправляет любое сообщение, и только один сервер в кластере может случайным образом потреблять это сообщение. Как показано ниже:

Потребление кластера.png

Широковещательное потребление: MQ отправляет каждое сообщение, и каждый сервер в кластере использует его хотя бы один раз. Как показано ниже:

Потребление вещания.png

Пример широковещательного потребления: система отправки сообщений. Сначала клиент устанавливает постоянное соединение с сервером в кластере приложений центра сообщений и сохраняет информацию о сеансе соединения в памяти текущего сервера.Когда кластер потребляет бизнес-сообщения, он не знает, где находится постоянное соединение, установленное клиентом. есть на сервере. В настоящее время благодаря потреблению широковещательной рассылки каждый сервер в кластере может получать бизнес-сообщения. Прежде чем принять решение отправить уведомление пользователю, он определит, есть ли информация о сеансе подключения клиента в текущей памяти сервера.Если да, оно будет отправлено, а затем клиент вытащит объект сообщения пользователя через протокол http. Если информация о сеансе отсутствует на текущем сервере, она будет удалена. Как показано ниже:

Пример потребления вещания.png

Примечания для широковещательного потребления:
1. Процесс потребления управляется на стороне потребителя.Например, папка смещения создается в основном каталоге по умолчанию, а файл смещения хранится в каталоге смещения.Вероятность дублирования больше, чем потребление кластера.
2. MQ может гарантировать, что каждое сообщение будет использовано каждым сервером-потребителем по крайней мере один раз, но если потребитель не сможет использовать его, он не будет выполнять повторную попытку, поэтому бизнес-сторона должна обратить внимание на сбой потребления.
3. Поскольку широковещательное сообщение о потреблении не будет подтверждено, отставание, отображаемое на терминале управления, останется неизменным, и превалирует логарифм.

Использование аналогового вещания с помощью кластера

В режиме публикации/подписки, если оно потребляется кластером, то сообщение может потребляться только случайным сервером в кластере. используйте широковещательное потребление для достижения. Однако широковещательное потребление имеет некоторые недостатки, например, оно не поддерживает последовательные сообщения, а вероятность повторного выполнения потребления при обслуживании клиента выше, чем в кластерном режиме, и процесс потребления не может поддерживаться в широковещательном режиме, поэтому число отставаний на сторона управления остается неизменной, мы должны Преобладать количество очередей, то есть запросы, которые не могут поддерживать накопление сообщений. Если мы хотим избежать этих недостатков, то мы можем использовать потребление кластера для имитации вещания.При потреблении кластера потребление APPID на каждом из наших серверов одинаковое.Если мы хотим добиться эффекта вещания, то потребление APPID на каждом из наших серверов сервер остается Просто быть другим.

аналоговое радио.png

повторите попытку

Повторить попытку.png

Функция повторных попыток MQ может гарантировать окончательную обработку результатов данных, но в то же время из-за повторных попыток особое внимание необходимо уделять проблеме идемпотентности во время бизнес-обработки. Например, в бизнесе удержания платежей после того, как система заказов сгенерирует заказ, она вызывает расчетную платформу, чтобы вычесть сумму счета пользователя. Расчетная платформа должна производить расчеты в соответствии с серийным номером.Если в системе заказов возникает сбой сети при вызове расчетной платформы, расчетная платформа фактически получила запрос и обработала его. Сторона системы заказов считает, что произошло исключение и его необходимо повторить, а последующие заказы, отправленные на расчетную платформу, приведут к повторным вычетам. Поэтому особое внимание следует уделить серийному номеру, чтобы убедиться, что серийный номер, отправляемый каждый раз в процессе повторной попытки, непротиворечив. Платформа расчетов будет проверять бизнес в соответствии с серийным номером. Если он был обработан, он будет удален. для обеспечения идемпотентности.

Суммировать

Мы представили распространенные сценарии использования MQ и меры предосторожности при использовании каждого сценария. Особенно в функции повтора повторение изначально является методом, предоставляемым MQ для сохранения данных, которые могут быть окончательно подтверждены, но если бизнес-использование не обращает внимания на идемпотентность, это приведет к несоответствиям в бизнес-данных, даже как повторные выводы. серьезные последствия. Мы также приводим пример использования широковещательного потребления в модели публикации/подписки, а также его недостатки и возможность использования кластерного потребления для имитации широковещательной рассылки. Ввиду того, что каждый из приведенных выше сценариев дает нам хорошее описание, чтобы каждый мог лучше сыграть мощную роль MQ в процессе использования MQ в будущем.

 

Ссылка: https://tech.meituan.com/mq-design.html

 

Обратите внимание на публичный аккаунт, чтобы синхронно обновлять технические статьи.