[Расширенная дорога] Очередь сообщений — принцип и выбор (1)

очередь сообщений

предисловие

Привет всем, я Нанджу. Прошло почти два года с тех пор, как я познакомился с java. За два года я прошел путь от супер-новичка, который даже не понимает несколько структур данных в java, до немного продвинутый младший Бай, многому научился. Чем больше знаний передается, тем они ценнее.За это время я обобщил (в том числе изучая и цитируя других воротил) некоторые ключевые моменты (самомышления) в моем обычном исследовании и интервью, надеясь принести вам некоторую помощь.

Нуждающиеся студенты могут добавить мой официальный аккаунт, последние статьи в будущем будут в нем впервые, или вы можете попросить у меня ментальную карту

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

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

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

1. Когда вам нужна очередь сообщений

  • Асинхронная обработка: Управляйте такими функциями, как доставка SMS, отправка статуса, регистрация пользователей, синхронизация данных и т. д., улучшайте возможности параллелизма системы, концентрируйтесь на обработке важных частей (обработка синхронизации) и оставляйте неосновные функции MQ.
  • Разделение системы: Разделение может быть достигнуто на различных уровнях детализации, таких как модули, службы и интерфейсы.
  • повторить компенсацию: Во всем процессе передачи данных между машинами, если какая-либо ссылка пойдет не так, это вызовет проблемы. Эти исключения можно максимально обработать с помощью механизма компенсации повторных попыток MQ.
  • Отключение трафика: Для обработки заказа в сценарии seckill. Получив сообщение, сервер сначала записывает его в очередь сообщений, а затем обрабатывает в соответствии со своими возможностями обработки сообщений.
  • обработка журнала: журналы можно регулярно записывать в MQ и активно подписываться на записи журналов.

Во-вторых, основная концепция очереди сообщений

1. Брокер сервера сообщений: сервер сообщений в качестве сервера для предоставления основных служб сообщений.

2. Производитель сообщений Производитель: отправка сообщений в очередь сообщений.

3. Потребитель сообщений Потребитель: Получайте сообщения из очереди сообщений.

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

  • 1,локальная очередь:

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

    ★初始化队列：用作消息触发功能。
    
    ★传输队列：是暂存待传的消息，条件许可的情况下，通过管道将消息传送到其他的队列管理器。
    
    ★目标队列：是消息的目的地，可以长期存放消息。
    
    ★死信队列：如果消息不能送达目标队列，也不能再路由出去，则被自动放入死信队列保存。
  • 2,Псевдонимическая очередь и удаленная очередь:

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

  • 3.модельная очередь:

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

5. Тема: Тема, унифицированный набор сообщений в режиме публикации-подписки, разные производители отправляют сообщения в тему, а сервер MQ распределяет их между разными подписчиками для реализации потребления сообщений.

6. Тело сообщения

3. Режим сообщений

1. PTP точка-точка

Функции:

  • У каждого сообщения есть только один потребитель (то есть после потребления сообщение больше не находится в очереди сообщений).
  • Между отправителем и получателем нет временной зависимости
  • Получатель должен успешно ответить в очередь после успешного получения сообщения.
  • Используя функцию FIFO «первым пришел — первым обслужен», можно гарантировать порядок сообщений.

Наконец, вместо того, чтобы заимствовать фотографии босса, я нарисую их для вас.

2. Pub/Sub публикация и подписка

Функции:

  • У каждого сообщения может быть несколько потребителей: в отличие от одноранговых, опубликованные сообщения могут потребляться всеми подписчиками.
  • Между издателями и подписчиками существует временная зависимость.
  • Для подписчика темы (Topic) он должен создать подписчика перед потреблением сообщений от издателя.
  • Чтобы получать сообщения, подписчики должны оставаться в рабочем состоянии.

Благодаря этим двум изображениям мы должны четко различать разницу между двумя режимами.

3. Часто используемые протоколы

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

1. АМКП

AMQP, Advanced Message Queuing Protocol, является открытым стандартом для протоколов прикладного уровня, разработанным для промежуточного программного обеспечения, ориентированного на сообщения. Промежуточное программное обеспечение сообщений в основном используется для разделения компонентов, отправителю сообщения не нужно знать о существовании потребителя сообщения, и наоборот. AMQP — это бинарный протокол, основными особенностями которого являютсяОриентированная на сообщения, ориентированная на очередь, маршрутизация (включая двухточечную связь и публикацию/подписку).

Сценарий приложений: когда простая модель публикации-подписки не может соответствовать требованиям использования.

Достоинства: Надежный, универсальный.

2. ТОМП

STOMP (протокол потокового текстового ориентированного сообщения) — это протокол потокового текстового ориентированного сообщения, простой текстовый протокол, разработанный для MOM (промежуточного программного обеспечения, ориентированного на сообщение). STOMP предоставляет интероперабельный формат соединения, который позволяет клиентам взаимодействовать с любым брокером сообщений STOMP (брокером), обычно действующим напубликовать-подписыватьсямодель.

Сценарий применения: Обмен информацией основан на тексте и требует простых сценариев.

Преимущества: командный режим (не топик\режим очереди)

3. XMPP

XMPP (расширяемый протокол обмена сообщениями и присутствия) — это протокол, основанный на расширяемом языке разметки (XML), который в основном используется для обмена мгновенными сообщениями (IM) и обнаружения присутствия в Интернете. Подходит для почти мгновенных операций между серверами. По своей сути потоковая передача на основе XML представляет собой протокол, который в конечном итоге может позволить пользователям Интернета отправлять мгновенные сообщения кому-либо еще в Интернете, даже с использованием других операционных систем и браузеров.Но формат кодирования XML требует большой пропускной способности..

Сценарий применения: максимально упростить клиент, а комплекс поставить на сервер.

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

4. СМС

JMS — это спецификация, основанная на брокере сообщений JVM, который представляет собой абстракцию более высокого уровня таких протоколов, как AMQP, MQTT, STOMP и XMPP. JMS — это API для промежуточного программного обеспечения, ориентированного на сообщения (MOM), на платформе Java, которое используется для отправки сообщений между двумя приложениями или распределенными системами для асинхронной связи.

Сценарий приложения: в системе Java несколько служб могут взаимодействовать через JMS без кода модификации приложения, но его поддержка кроссплатформенности оставляет желать лучшего.

Достоинства: асинхронный, надежный

Четыре, обычно используемый сравнительный анализ MQ

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

1. RocketMQ

RocketMQ — с открытым исходным кодом под системой Али.Распределенное ПО промежуточного слоя для сообщений модели очереди, ранее известный как Metaq, название версии 3.0 было изменено на RocketMQ, который представляет собой набор MQ, реализованный Али с использованием Java со ссылкой на дизайнерскую идею Кафки. В то же время он интегрирует различные продукты MQ (Notify, metaq) в отдел Alibaba, поддерживает только основные функции, удаляет все другие зависимости времени выполнения и обеспечивает простейшие основные функции.На этой основе он сотрудничает с другими открытыми подразделениями Alibaba. исходные продукты для реализации различных сценариев Архитектура MQ в настоящее время в основном используется в системах торговли ордерами.

Функции:

  • На основе модели очереди: она имеет характеристики высокой производительности, высокой надежности, высокого режима реального времени, распределенной и т. д.;
  • Producer, Consumer и Queue поддерживают распределенную поддержку;
  • Производитель отправляет сообщения по очереди в некоторые очереди, а набор очередей называется топиком. Если Потребитель выполняет широковещательное потребление, один экземпляр Потребителя потребляет все очереди, соответствующие этой теме.Если он используется для потребления кластера, несколько экземпляров Потребителя в среднем потребляют набор очередей, соответствующий этой теме;
  • Может гарантировать строгий порядок сообщений;
  • Обеспечьте расширенный режим извлечения сообщений;
  • Эффективная горизонтальная масштабируемость абонента;
  • Механизм подписки на сообщения в реальном времени;
  • Возможность накопления сообщений на миллиардном уровне;
  • Меньше внешних зависимостей.

преимущество:

  • Все сообщения RocketMQ являются персистентными.Они сначала записываются в системный PAGECACHE, а затем сбрасываются, чтобы и в памяти, и на диске была копия данных.При доступе они считываются напрямую из памяти;
  • Модель проста, а интерфейс прост в использовании (интерфейсы JMS во многих случаях не очень практичны);
  • Производительность очень хорошая, что позволяет накапливать большое количество сообщений в Брокере;
  • Поддержка различных режимов потребления, включая кластерное потребление, широковещательное потребление и т. д.;
  • Распределенный дизайн расширения каждого канала для поддержки ведущий-ведомый и высокой доступности;
  • Степень разработки более активна, а обновление версии происходит очень быстро.

недостаток:

  • Существует не так много поддерживаемых клиентских языков, в настоящее время Java и C++, из которых C++ является незрелым;
  • Внимание и зрелость сообщества RocketMQ не так хороши, как первые два;
  • Нет веб-интерфейса управления, но предоставляется инструмент управления CLI (интерфейс командной строки) для запроса, управления и диагностики различных проблем;
  • Такие интерфейсы, как JMS, не реализованы в ядре MQ;

2. КроликMQ

Очередь сообщений с открытым исходным кодом, написанная на Erlang, сам поддерживает множество протоколов: AMQP, XMPP, SMTP, STOMP, что делает его очень тяжелым и более подходящим для разработки на уровне предприятия. В то же время реализована архитектура Broker.Основная идея заключается в том, что производитель не будет отправлять сообщение напрямую в очередь, а сообщение будет помещено в центральную очередь при отправке клиенту.Хорошая поддержка маршрутизации, балансировки нагрузки и сохранения данных.. В основном используется для интеграции ESB на уровне предприятия.

Функции:

  • Надежность. Предоставляются различные методы, позволяющие найти компромисс между производительностью и надежностью. Эти методы включают механизмы сохранения, подтверждение доставки, подтверждение издателя и механизмы высокой доступности;
  • Гибкая маршрутизация: сообщения направляются через коммутаторы до того, как попадут в очередь. RabbitMQ предоставляет несколько встроенных типов коммутаторов для типичной логики маршрутизации. Если у вас есть более сложные требования к маршрутизации, вы можете использовать эти переключатели в комбинации, и вы даже можете реализовать свой собственный тип переключателя и использовать его как подключаемый модуль RabbitMQ;
  • Кластеризация сообщений: несколько серверов RabbitMQ в одной и той же локальной сети могут быть объединены вместе и использоваться как независимый логический агент;
  • Высокая доступность очередей: очереди могут быть зеркалированы на машинах в кластере для обеспечения безопасности сообщений в случае аппаратных проблем;

Поддержка нескольких протоколов: поддержка нескольких протоколов очереди сообщений;

  • Поддерживает несколько языков: написан на Erlang, поддерживает все языки программирования, о которых вы только можете подумать;
  • Интерфейс управления: RabbitMQ имеет простой в использовании пользовательский интерфейс, который позволяет пользователям отслеживать и управлять многими аспектами брокера сообщений;
  • Механизм отслеживания: если сообщение является ненормальным, RabbitMQ предоставляет механизм отслеживания сообщений, и пользователь может узнать, что произошло;
  • Механизм подключаемых модулей: Многие подключаемые модули предоставляются для расширения различными способами, или вы можете написать свои собственные подключаемые модули.

преимущество:

  • Из-за особенностей языка Erlang очередь сообщений имеет лучшую производительность и поддерживает высокий параллелизм;
  • Надежный, стабильный, простой в использовании, кроссплатформенный, поддерживает несколько языков и имеет полную документацию;
  • Имеется механизм подтверждения сообщения и механизм сохраняемости, а надежность высокая;
  • Настраиваемая маршрутизация;
  • Богатый интерфейс управления, масштабные приложения в интернет-компаниях и высокая активность сообщества

недостаток:

  • Хотя в сочетании с преимуществами параллелизма самого языка Erlang, производительность выше, но это не способствует вторичной разработке и обслуживанию;
  • Реализована архитектура брокера, что означает, что сообщения могут ставиться в очередь на центральном узле перед отправкой клиентам. Эта функция делает RabbitMQ простым в использовании и развертывании, но заставляет его работать медленнее, потому что центральный узел увеличивает задержку, а инкапсуляция сообщений больше; ему нужно изучать более сложные интерфейсы и протоколы, а стоимость обучения и обслуживания высока. .

3. ActiveMQ

Подпроект под Apache. Используя реализацию поставщика JMS, которая полностью поддерживает спецификации JMS1.1 и J2EE 1.4 в Java,Расширенные сценарии приложений можно эффективно реализовать с помощью небольшого объема кода. Поддержка подключаемого транспортного протокола, например: in-VM, TCP, SSL, NIO, UDP, multicast, транспорты JGroups и JXTA. RabbitMQ, ZeroMQ, ActiveMQ поддерживают часто используемые многоязычные клиенты C++, Java, .Net, Python, Php, Ruby и т. д.

Функции:

  • Соответствие спецификации JMS: Спецификация JMS обеспечивает хорошие стандарты и гарантии, в том числе: синхронное или асинхронное распространение сообщений, однократное и однократное распространение сообщений, прием и подписка на сообщения и т. д. Преимущество следования спецификации JMS заключается в том, что эти основные функции доступны независимо от используемого поставщика реализации JMS;
  • Гибкость подключения: ActiveMQ предоставляет широкий спектр протоколов подключения, поддерживаемые протоколы: HTTP/S, IP-многоадресная рассылка, SSL, TCP, UDP и так далее. Поддержка многих протоколов дает ActiveMQ большую гибкость;

Существует много типов поддерживаемых протоколов: OpenWire, STOMP, REST, XMPP, AMQP;

  • Плагины сохранения и плагины безопасности: ActiveMQ предоставляет множество вариантов сохранения. Кроме того, безопасность ActiveMQ также можно полностью настроить в соответствии с потребностями пользователя в отношении аутентификации и авторизации;
  • Существует много типов поддерживаемых клиентских языков: кроме Java есть: C/C++, .NET, Perl, PHP, Python, Ruby;

Кластер брокера: несколько брокеров ActiveMQ могут образовывать кластер для предоставления услуг;

  • Невероятно простое управление: ActiveMQ был разработан с учетом потребностей разработчиков. Таким образом, он не требует специального администратора, так как предоставляет простые и удобные функции управления. Существует множество способов мониторинга данных ActiveMQ на разных уровнях, включая использование JConsole или использование JMX в WebConsole ActiveMQ. Путем обработки предупреждающих сообщений JMX, использования сценариев командной строки и даже мониторинга различных типов журналов.

преимущество:

  • Кроссплатформенность (написание JAVA никак не связано с платформой, ActiveMQ может работать практически на любой JVM);
  • Можно использовать JDBC: данные можно сохранять в базе данных. Хотя использование JDBC снизит производительность ActiveMQ, база данных всегда была наиболее привычным для разработчиков носителем данных;
  • Поддержка спецификации JMS: поддержка унифицированного интерфейса, предоставляемого спецификацией JMS;
  • Поддержка автоматического повторного подключения и механизма повторной попытки ошибки;
  • Существует механизм безопасности: он поддерживает различные механизмы настройки безопасности, основанные на shiro, jaas и т. д., и может выполнять аутентификацию и авторизацию Queue/Topic;
  • Идеальный мониторинг: имеет идеальный мониторинг, включая WebConsole, JMX, командную строку Shell, RESTful API Jolokia;
  • Дружественный интерфейс: предоставляемая веб-консоль подходит для большинства ситуаций, и можно использовать множество сторонних компонентов, таких как hawtio;

недостаток:

  • Активность сообщества невысока;
  • Согласно другим отзывам пользователей, будут необъяснимые проблемы, и сообщения будут потеряны;
  • Не подходит для сценариев приложений с тысячами очередей;

4. Кафка

Kafka изначально была разработана LinkedIn с использованием языка Scala.Распределенная, многораздельная, распределенная система обмена сообщениями с несколькими копиями, основанная на координации зоопарка., теперь переданный в дар Apache Foundation. Это высокопроизводительная распределенная система обмена сообщениями публикации и подписки, которая широко используется благодаря своей горизонтальной масштабируемости и высокой пропускной способности. В настоящее время все больше и больше систем распределенной обработки с открытым исходным кодом, таких как Cloudera, Apache Storm, Spark, Flink и т. д., поддерживают интеграцию с Kafka.

Функции:

  • Быстрое сохранение: сохранение сообщений может выполняться с системными издержками O(1);
  • Высокая пропускная способность: на обычном сервере может быть достигнута пропускная способность 10 Вт/с;
  • Полностью распределенная система: брокер, производитель и потребитель изначально и автоматически поддерживают распределение и автоматически обеспечивают балансировку нагрузки;

Поддержка двух механизмов высокой доступности, синхронного и асинхронного;

  • Поддержка пакетной отправки и извлечения данных;
  • Технология нулевого копирования (zero-copy): сокращение операций ввода-вывода и повышение пропускной способности системы;
  • Миграция и расширение данных прозрачны для пользователей;
  • Расширение машины без простоев;
  • Другие функции: богатая модель извлечения сообщений, эффективное горизонтальное расширение подписчиков, подписка на сообщения в реальном времени, возможность накопления сообщений на уровне 100 миллионов и механизм регулярного удаления;

преимущество:

  • Богатый клиентский язык: поддержка Java, .Net, PHP, Ruby, Python, Go и других языков;
  • Высокая производительность: одна машина записывает около 1 миллиона TPS в секунду, а размер сообщения составляет 10 байт;
  • Обеспечивает полностью распределенную архитектуру с механизмом репликации, которая обладает высокой доступностью и надежностью и теоретически поддерживает бесконечное накопление сообщений;
  • Поддержка пакетных операций;
  • Потребители используют метод Pull для получения сообщений. Сообщения упорядочены, и контроль может гарантировать, что все сообщения потребляются и потребляются только один раз;
  • Есть отличный сторонний интерфейс управления KafkaWeb Kafka-Manager;
  • Он относительно зрел в области ведения журналов и используется многими компаниями и проектами с открытым исходным кодом.

недостаток:

  • Когда одна машина Kafka имеет более 64 очередей/разделов, будет очевидный всплеск нагрузки. Чем больше очередей, тем выше нагрузка и больше время ответа на отправку сообщений;
  • При использовании метода короткого опроса производительность в реальном времени зависит от интервала опроса;
  • Ошибка потребления не поддерживает повторную попытку;
  • Порядок сообщений поддерживается, но когда агент выйдет из строя, сообщения будут не в порядке;
  • Сообщения обновляются медленно.

5. Сравнение четырех основных MQ

По сравнению со многими студентами, которые видели эту фотографию, я опубликую ее для вас:

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

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

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

С точки зрения параллелизма: RabbitmqMQ и RocketMQ — хорошие варианты.

Кроме того, позиционирование Kafka в основном связано с аспектами журналов, поскольку первоначальным намерением дизайна Kafka является обработка журналов, его можно рассматривать как важный компонент системы журналов (сообщений), и он очень целенаправленный, поэтому рекомендуется выбирать RabbitMq для бизнеса.

Кроме того, производительность Kafka (пропускная способность, TPS) намного выше, чем у RabbitMq.

Эпилог

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

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

Категории