__Лучшего нет, есть только правильный
предисловие
Очереди сообщений настолько широко используются в хранилищах интернет-технологий, что почти всем техническим интервьюерам приходится усложнять 360° своим друзьям с точки зрения использования и принципов очередей сообщений.
В прошлый раз я упомянул несколько проблем с введением очередей сообщений
Что, так много вопросов все еще используют пердеть! Не паникуйте, приходите и найдите решение прямо сейчас.
Высокая доступность
Основной MQ имеет режим высокой доступности, из которого мы можем выбирать!
RabbitMQ может использовать режим зеркального отображения для создания кластера высокой доступности, и вы можете настроить синхронизацию данных на все узлы или на определенное количество узлов в соответствии с фактическими потребностями.
RocketMQ и Kafka имеют естественно распределенный дизайн, поэтому у них, естественно, есть высокодоступные навыки ^^
Можно выбрать режим асинхронной репликации RocketMQ с несколькими ведущими и несколькими подчиненными устройствами, режим синхронной двойной записи с несколькими ведущими устройствами и несколькими подчиненными устройствами и несколько режимов развертывания кластера.
Схема архитектуры развертывания в режиме с несколькими ведущими и несколькими подчиненными:
Потребитель отличается от других, он устанавливает долгосрочные соединения с Мастером и Слейвом, которые одновременно предоставляют услуги Темы, Он может подписываться на сообщения от Мастера или от Слейва Правила подписки определяются конфигурацией Брокера.
Архитектура Kafka очень похожа на RocketMQ.
В кластере много брокеров для укладки сообщений, Kafka поддерживает горизонтальное расширение, как правило, чем больше брокеров, тем выше пропускная способность кластера.
Производители используют режим push для публикации сообщений брокерам.
Потребители подписываются и получают сообщения от брокеров, используя режим получения.
Повторное потребление
Теперь очереди сообщений, как правило, гарантированно будут хотя бы один раз, то есть сообщения будут доставлены хотя бы один раз.
В таком случае, почему возникает проблема повторного потребления?
Обычно это вызвано сетевыми причинами, причины следующие:
Обычно после того, как сообщение успешно обработано, потребитель отправляет MQ флаг успеха. Когда MQ получает этот флаг, это означает, что сообщение успешно обработано и не будет отправлено другим потребителям.
Однако, если оно потеряно из-за того, что флаг сети не отправлен в MQ, MQ считает, что сообщение не было успешно использовано, и оно будет снова отправлено другим потребителям для использования, что приведет к дублированию.
В это время, когда мы смотрим на эту проблему, это становится того, как мы обеспечиваем идемпотентность потребительской стороны.
Идемпотентность означает, что влияние операции, выполняемой любое количество раз, такое же, как и влияние одного выполнения.
Проще говоря, вы вызываете мой интерфейс с одними и теми же параметрами, и результат один и тот же независимо от того, сколько раз вы его вызываете.
Идемпотентность требует подробного рассмотрения в соответствии с бизнес-требованиями, но основной принцип заключается в следующем.дедупликацияКак правило, его можно разделить на сильную проверку и слабую проверку.
-
Сильный чек Вообще, финансовые операции строго проверяются 😜 (люди в 996, а горшок с неба приходит и ускользает)
Например, потребительское обслуживание - это сыгранные деньги, после успеха оплаты добавит запись воды. И две операции в транзакцию.
Когда вы снова потратите, вы перейдете к списку воды, чтобы проверить, есть ли эта запись.Если у вас есть расходы, вы вернули их напрямую. Счетчик воды тоже может сыграть свою роль!
Некоторые простые сценарии также могут полагаться на уникальные ограничения базы данных для достижения -
Слабая контрольная сумма Этот менее строгий, и повторять его не так важно.
Вы можете сохранить идентификатор в наборе Redis, а время истечения срока действия зависит от ситуации.
Если невозможно гарантировать уникальность идентификатора, производитель может сгенерировать токен и сохранить его в redis, а потребитель удалит его после потребления (операция redis может гарантировать его атомарность, и если удаление не удастся, он вернет 0)
сообщение потеряно
Почему некоторые новости пропадают после запуска? 💔
Вообще говоря, существует три способа потери сообщения:
- Производитель теряет данные
Основной MQ имеет механизм подтверждения или механизм транзакций, который может гарантировать, что производитель отправит сообщение MQ. Например, RabbitMQ имеет режим транзакций и режим подтверждения. - очередь сообщений потеряла данные
Как правило, эту проблему можно решить, если включена конфигурация постоянного диска MQ, и вы можете быть уверены при записи на диск. - Потребители теряют данные
Данные потребителей, как правило, потому что используется режим автоматического сообщения подтверждения. MQ удалит сообщение после получения подтверждающего сообщения.Если потребитель ненормальный, сообщение исчезнет. Вы можете решить эту проблему с ручным подтверждением!
последовательное сообщение
Сценарий последовательных сообщений может использоваться меньше, но все же есть некоторые
Например, в операции заказа электронной коммерции после размещения заказа сократите запасы, а затем создайте заказ Эта операция должна выполняться последовательно.
Как гарантировать заказ?
- В первую очередь продюсеру необходимо обеспечить порядок вхождения в команду, ведь даже самый мощный MQ не выдерживает хаоса при вступлении в команду.
- Общий MQ может гарантировать, что внутренняя очередь является FIFO (первым пришел, первым обслужен), но это только для одной очереди, поэтому ее можно использовать при отправке сообщений.Метод хеширования по модулюОтправляйте сообщения о той же операции в одну и ту же очередь, так что очередь гарантирована в порядке.
- Потребители также должны быть осторожны, если несколько потребителей используют очередь одновременно. То же самое может происходить не по порядку. Это эквивалентно многопоточному потреблению!
Проблема последовательного потребления сообщений в основном может быть решена с помощью вышеописанных приемов!
Увидимся!