1. Введение в MQ

1.1, что такое очередь сообщений

Очередь сообщений (Message Queue) — это способ межпроцессного взаимодействия или связи между разными потоками одного и того же процесса. С точки зрения непрофессионала, очередь сообщений — это контейнер для хранения сообщений, и это структура данных «первым пришел — первым вышел».

1.2 Когда вам нужны очереди сообщений?

1.2.1 Асинхронная обработка (SMS-уведомление, отправка электронной почты, отправка статуса терминала, отправка приложения и т. д.)

   有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

Описание сценария:После того, как пользователь зарегистрирован, необходимо отправить зарегистрированное электронное письмо и зарегистрированное SMS.

Существует два традиционных метода: 1. Последовательный способ 2. Параллельный способ

(1),Серийный способ:После того, как регистрационная информация будет успешно записана в базу данных, отправьте регистрационное электронное письмо, а затем отправьте регистрационное SMS. После того, как все три вышеуказанные задачи будут выполнены, вернитесь к клиенту.

(2),Параллельный путь:После того, как регистрационная информация будет успешно записана в базу данных, регистрационное SMS будет отправлено одновременно с регистрационным электронным письмом. После выполнения трех вышеуказанных задач вернитесь к клиенту.Отличие от серийного:Параллелизм может улучшить время обработки

Предполагая, что каждый из трех бизнес-узлов использует 50 миллисекунд, без учета других накладных расходов, таких как сеть, последовательное время составляет 150 миллисекунд, а параллельное время может составлять 100 миллисекунд.

Поскольку количество запросов, обрабатываемых ЦП в единицу времени, фиксировано, предполагается, что пропускная способность ЦП составляет 100 запросов в секунду. Тогда количество запросов, которые ЦП может обработать за 1 секунду в последовательном режиме, равно 7 раз (1000/150). Количество параллельно обрабатываемых запросов 10 раз (1000/100)

Внедрение очереди сообщений не будет необходимо для бизнес-логики, асинхронной обработки. Модифицированная структура выглядит следующим образом:

Согласно приведенному выше соглашению, время отклика пользователя эквивалентно времени записи регистрационной информации в базу данных, то есть 50 миллисекундам. После регистрации электронного письма, отправки короткого сообщения и записи его в очередь сообщений оно возвращается напрямую, поэтому скорость записи в очередь сообщений очень высока и может быть в основном проигнорирована, поэтому время отклика пользователя может составлять 50 миллисекунд. Итак, после изменения архитектуры пропускная способность системы увеличилась до 20 в секунду.QPS.В 3 раза быстрее последовательного и в 2 раза быстрее параллельного.

1.2.2. Разделение приложений

Описание сценария:После того, как пользователь размещает заказ, система заказов должна уведомить систему инвентаризации и платежную систему. Традиционный подход заключается в том, что система заказов вызывает интерфейс системы инвентаризации и платежной системы. Как показано ниже

Недостатки традиционного режима:

Если доступ к системе инвентаризации или оплате невозможен, заказ не сможет сократить запасы или платеж не будет выполнен, что приведет к сбою заказа.
Система заказов связана с системой инвентаризации

Как решить вышеуказанные проблемы? Решение после введения очереди сообщений приложения выглядит следующим образом:

Система заказов: после того, как пользователь размещает заказ, система заказов завершает постоянную обработку, записывает сообщение в очередь сообщений и возвращает успешность заказа пользователя.

Система инвентаризации: подпишитесь на новости о заказе и используйте метод pull/push для получения информации о заказе.Система инвентаризации выполняет операции инвентаризации в соответствии с информацией о заказе.

Инвентарная система: подписывайтесь на новости заказа, используйте метод pull/push для получения информации о заказе, а платежная система выполняет платежную операцию в соответствии с информацией о заказе.

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

1.2.3 Отсечение пика потока

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

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

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

В общем, для обеспечения стабильности системы, если загрузка системы превышает пороговое значение, запрос пользователя будет заблокирован, что повлияет на работу пользователя, а если запрос кэшируется с использованием очереди сообщений, и система будет уведомлять пользователя о том, что заказ выполнен после обработки, поэтому лучше никогда не размещать заказ.

В экономических целях:

Если QPS бизнес-системы в обычные часы составляет 1000, а самый высокий пик трафика 10000, очевидно, что настраивать высокопроизводительный сервер для работы с пиком трафика нерентабельно, в этом случае вы можете использовать сообщение очереди для снижения пикового трафика.

1.2.4 Распространение контента

Данные могут передаваться между несколькими системами через очереди сообщений. Генератору данных не нужно заботиться о том, кто использует данные, ему нужно только отправить данные в очередь сообщений, а потребитель данных может напрямую получить данные из очереди сообщений.

1.3 Преимущества и недостатки MQ

Преимущества: асинхронная обработка, развязка, сглаживание пиков, распределение данных.

Недостатки включают следующее:

Снижение доступности системы

Чем больше внешних зависимостей вводит система, тем хуже стабильность системы. Как только MQ выйдет из строя, это повлияет на бизнес.

Как обеспечить высокую доступность MQ?
Повышенная сложность системы

Добавление MQ значительно увеличивает сложность системы.В прошлом синхронные удаленные вызовы выполнялись между системами, но теперь асинхронные вызовы выполняются через MQ.

Как сделать так, чтобы сообщения не использовались повторно? Как бороться с потерянными сообщениями? Так упорядоченность доставки сообщений гарантирована?
Проблемы согласованности

После того, как система A обработает бизнес, она отправляет данные сообщения в системы B, C и D через MQ. Если система B и система C обрабатывают успешно, система D дает сбой.

Как обеспечить согласованность обработки данных сообщения?

1.4 Основные критерии выбора очередей сообщений

Хотя у этих очередей сообщений есть свои преимущества и недостатки с точки зрения функций и возможностей, при их выборе у нас должен быть базовый стандарт.

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

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

Наконец, в качестве квалифицированной очереди сообщений должны быть реализованы следующие функции:

надежная доставка сообщений: убедитесь, что ни одно сообщение не потеряно;
Cluster: поддержка кластеризации, чтобы гарантировать, что служба не будет недоступна из-за простоя узла, и, конечно же, чтобы не потерять сообщения;
представление: имеет достаточную производительность для удовлетворения требований большинства сценариев.

Далее давайте взглянем на очереди сообщений с открытым исходным кодом, которые соответствуют указанным выше условиям и могут быть выбраны.

1.4.1 RabbitMQ

Во-первых, давайте взглянем на очередь сообщений RabbitMQ. Выпущенный в 2007 году RabbitMQ написан на языке программирования Erlang, изначально предназначенном для надежной связи между системами в телекоммуникационной отрасли, и является одной из немногих очередей сообщений, поддерживающих протокол AMQP.

RabbitMQ: Легкий и быстрый, его слоган также ясно показывает характеристики RabbitMQ: Обмен сообщениями, который просто работает, готовая очередь сообщений. То есть RabbitMQДовольно легкая очередь сообщений, которую очень легко развернуть и использовать..

Более отличительной чертой RabbitMQ являетсяПоддерживает очень гибкую конфигурацию маршрутизации, в отличие от других очередей сообщений, добавляет модуль Exchange между производителем (Producer) и очередью (Queue), что можно понимать как обмен.

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

Клиент RabbitMQ поддерживает, наверное, большинство языков программирования из всех очередей сообщений.

Далее давайте поговорим о нескольких вопросах о RabbitMQ:

Поддержка RabbitMQ для накопления сообщений не очень хороша, когда большое количество сообщений задерживается, производительность RabbitMQ резко падает.
Производительность RabbitMQ является наихудшей среди этих очередей сообщений, и он может обрабатывать от десятков тысяч до сотен тысяч сообщений в секунду. Если у приложения очень высокие требования к производительности очереди сообщений, не выбирайте RabbitMQ.
Язык программирования Erlang, используемый RabbitMQ, требует больших затрат на расширение и вторичную разработку.

1.4.2 RocketMQ

RocketMQ — это продукт очереди сообщений с открытым исходным кодом от Alibaba, выпущенный в 2012 году. Он реализован на языке Java. Он был разработан со ссылкой на Kafka и внес некоторые собственные улучшения. Позже он был передан в дар Apache Software Foundation. стал вершиной проекта Apache. RocketMQ широко используется в Alibaba для заказов, транзакций, пополнения, потоковых вычислений, отправки сообщений, обработки потока журналов, распространения Binglog и других сценариев. Он прошел множество тестов двойного одиннадцати, и его производительность, стабильность и надежность заслуживают доверия.

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

RocketMQ имеетОчень активное китайское сообщество, на большинство вопросов можно ответить на китайском языке. RocketMQ разработан на языке Java, а исходный код относительно прост для чтения и понимания.RocketMQ легко расширить или доработать..

RocketMQ значительно оптимизировал задержку ответа онлайн-сервисов, что можно сделать в большинстве случаев.миллисекундный отклик, если ваш сценарий приложения очень обеспокоен задержкой ответа, вам следует использовать RocketMQ.

Производительность RocketMQ на порядок выше, чем у RabbitMQ,Может обрабатывать сотни тысяч сообщений в секунду.

Недостатком RocketMQ является то, что он интегрирован и недостаточно совместим с уровнем окружающей экосистемы.

1.4.3 Kafka

Апач Кафка — этоРаспределенная система публикации и подписки на сообщения. Первоначально он был реализован LinkedIn как распределенная система отправки журналов на основе уникального дизайна, а позже стал частью проекта Apache.

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

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

Кафка иСовместимость окружающей экосистемы — одна из лучших, особенно в области больших данных и потоковых вычислений, почти все связанные системы программного обеспечения с открытым исходным кодом будут отдавать приоритет поддержке Kafka.

Kafka эффективна, масштабируема и надежна. Его функции секционирования, репликация и отказоустойчивость — все это хорошие функции.

Использование КафкиЯзыки Scala и JavaПри разработке и дизайне используется множество пакетных и асинхронных идей, благодаря чему Kafka может достичь сверхвысокой производительности. Производительность Kafka, особенно производительность асинхронной отправки и получения, является лучшей среди трех, но разница с RocketMQ не на порядок, примерноМожет обрабатывать сотни тысяч сообщений в секунду.

При достаточном количестве клиентов, одновременно отправляющих асинхронные пакеты и включенном сжатии, максимальная вычислительная мощность Kafka может превысить 20 миллионов сообщений в секунду.

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

1.5 Сравнение различных продуктов MQ

Общие продукты MQ включают RabbitMQ, RocketMQ и Kafka.

характеристика	RabbitMQ	RocketMQ	Kafka
Язык разработки	erlang	java	scala
Производительность одной машины	10000 класс	сто тысяч	сто тысяч
Своевременность	нам класс	мс уровень	в течение мс
Доступность	Высокий (архитектура ведущий-ведомый)	Очень высокий (распределенная архитектура)	Очень высокий (распределенная архитектура)
надежность	В принципе не потерял	После настройки оптимизации параметров можно достичь нулевой потери	После настройки оптимизации параметров можно достичь нулевой потери
Функции	Разработан на основе erlang, с сильным параллелизмом, отличной производительностью и низкой задержкой.	MQ имеет относительно полные функции, все еще распределен и имеет хорошую масштабируемость.	Он поддерживает только основные функции MQ, такие как информационный запрос некоторых очередей сообщений, отслеживание сообщений и другие функции не предусмотрены, ведь он подготовлен для больших данных и широко используется в области больших данных.

Малые и средние компании, техническая мощь относительно общая, технические проблемы не особенно высоки, и RabbitMQ — хороший выбор;большая компания(Наша компания, безусловно, будет развиваться в этом направлении), инфраструктурные исследования и разработки сильны, и RocketMQ — хороший выбор.

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