По замыслу автора,очередь сообщений,кэш,Подбаза данных и подтаблицаЭто три мушкетера решений с высоким уровнем параллелизма.。

За свою карьеру я использовал известные очереди сообщений, такие как ActiveMQ, RabbitMQ, Kafka и RocketMQ.

Эта статья,Автор объединяет собственный реальный опыт,поделиться со всеми Семь классических сценариев применения очередей сообщений。

1 асинхронный&развязка

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

На картинке,Добавить нового пользователяиотправка текстового сообщенияВсе в пользовательском центре Служитьвнутри,Недостатки этого метода весьма очевидны:

1. Если интерфейс SMS-канала работает нестабильно, отредактируйте текстового сообщения Произошел тайм-аут,Интерфейс регистрации пользователя занимает очень много времени.,Влияние на взаимодействие с пользователем;
2. Изменения интерфейса SMS-канала,Код центра пользователя необходимо изменить. Но пользовательский центр — это ядро ​​системы. Вам нужно быть осторожным каждый раз, когда вы выходите в Интернет. Это очень неловко,Неосновные функции влияют на основную систему.

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

• асинхронный:Пользовательский центр Служить После успешного сохранения информации о пользователе,Отправить сообщение наочередь сообщений , Немедленно верните результаты во внешний интерфейс, что позволит избежать проблем, занимающих много времени и влияющих на взаимодействие с пользователем.
• Развязка:Задача Служить Получить SMS-сообщение Служитьотправка текстового сообщения,Удалить основной функционал от неосновного,Значительно снижает связь между системами.

2 Устранение пика

В сценарии с высокой степенью параллелизма внезапные пики запросов могут легко привести к нестабильной работе системы. Например, большое количество запросов на доступ к базе данных создаст большую нагрузку на базу данных, или системные ресурсы ЦП и ввода-вывода могут столкнуться с узкими местами.

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

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

3-шина сообщений

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

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

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

Архитектурный проект шины сообщений может сделать систему более развязанной и позволить каждой системе выполнять свои собственные обязанности.

4 Отложенные задачи

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

очень элегантныйиз Путь：Задержанные сообщения с использованием очереди сообщений。

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

Код для производителя RocketMQ 4.X для отправки отложенных сообщений выглядит следующим образом:

Message msg = new Message();
msg.setTopic("TopicA");
msg.setTags("Tag");
msg.setBody("this is a delay message".getBytes());
//Установим уровень задержки 5, что соответствует задержке в 1 минуту
msg.setDelayTimeLevel(5);
producer.send(msg);

Версия RocketMQ 4.X по умолчанию поддерживает 18 уровней отложенных сообщений, что определяется элементом конфигурации messageDelayLevel на стороне брокера.

Версия RocketMQ 5.X поддерживает задержку сообщений в любое время. Клиент предоставляет 3 API для указания времени задержки или времени при построении сообщения.

5 Потребление радио

потребление радио是指每条Push-сообщениевсем в кластереизпотребитель,Убедитесь, что сообщение использовано хотя бы один раз каждым потребителем.

потребление радио В основном используется в двух сценариях：Push-сообщениеикэшSync。

01 Отправка сообщения

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

Служба push — это служба TCP (пользовательский протокол) и потребительская служба. Режим сообщений — широковещательное потребление.

После того, как драйвер откроет приложение драйвера, приложение создаст длинное соединение посредством балансировки нагрузки и службы push-уведомлений, а служба push-уведомлений сохранит ссылку на TCP-соединение (например, номер драйвера и ссылку на TCP-канал).

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

02 Синхронизация кэша

В сценариях с высоким уровнем параллелизма многие приложения используют локальный кэш для повышения производительности системы.

Локальным кешем может быть HashMap, ConcurrentHashMap или платформа кэширования Guava Cache или Caffeine Cache.

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

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

6 Распределенные транзакции

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

1. Традиционное решение для транзакций XA: недостаточная производительность

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

2. На основе обычной схемы сообщений: сложность обеспечения последовательности

В этом решении нисходящая ветвь сообщения и основная ветвь системы заказов подвержены несоответствиям, например:

• Сообщение успешно отправлено,Заказ не был выполнен успешно,Нужно откатить всюиндивидуальныйдела。
• Заказ был выполнен успешно, но сообщение не было успешно отправлено, и для обнаружения несоответствия потребовалась дополнительная компенсация.
• Тайм-аут отправки сообщения неизвестен. В настоящее время невозможно определить, следует ли откатить заказ или отправить изменения в заказ.

3. На основе сообщений распределенных транзакций RocketMQ: поддерживает итоговую согласованность.

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

И на основе RocketMQ выполнитьиз Распределенные транзакции Функция сообщения,На основе обычных новостей,Второй этап поддержкииз Отправить возможность。Привяжите двухэтапную отправку к локальным транзакциям, чтобы добиться согласованности результатов глобальной отправки.。

Процесс взаимодействия показан на рисунке ниже:

1. Производитель отправляет сообщение Брокеру.

2、Broker После успешного сохранения сообщения верните его производителю. Ack Подтверждающее сообщение было успешно отправлено,На этом этапе сообщение помечается как"Пока не доступен для доставки",в этом состояниииз Сообщениеполутранзакционные сообщения。

3、продюсер начинаетВыполнять логику локальной транзакции。

4、Производители на базе местныхдела Результаты выполнения до СлужитьконецОтправьте результаты вторичного подтверждения（ Commit Или Rollback ）,Broker Логика обработки после получения результата подтверждения следующая:

• Результат второго подтверждения: Commit ：Broker Будут полутранзакционные Сообщение помечается как доставляемое и доставляется потребителю.
• Результат второго подтверждения: Rollback ：Broker Откатим дела,Ни в коем случае полутранзакционные сообщения, доставленные потребителям.

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

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

7 Центр передачи данных

За последние 10 лет появились специальные системы, такие как хранилище KV (HBase), поиск (ElasticSearch), потоковая обработка (Storm, Spark, Samza), база данных временных рядов (OpenTSDB) и другие специальные системы. Эти системы были созданы с единственной целью, а их простота упрощает и делает более экономичным создание распределенных систем на стандартном оборудовании.

Часто один и тот же набор данных необходимо ввести в несколько специализированных систем.

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

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

1. бревно коллекторский клиент,Отвечает за сбор данных различных пользовательских приложений.,Отправляйте бревно «пакетно» и «асинхронно» клиенту Kafka в виде сообщений. Пакет клиента Kafka фиксирует и сжимает сообщения,Влияние на производительность приложения Служить очень незначительно.
2. Kafka хранит сообщения в файлах сообщений для обеспечения устойчивости.
3. бревно обрабатывающие приложения, такие как Логсташ подписывается и потребляет бревно сообщения в Kafka, в конечном итоге для поиска файлов. Kafka доставить сообщение Hadoop и другие приложения для больших данных, системное хранение и анализ.