предисловие

Есть много отличных промежуточных программ по очереди в сообществе с открытым исходным кодом, таким как rabritmq и кафка. Кажется, что кажется, что каждая очередь имеет свои собственные характеристики. При совершении инженерных выборов это часто ослепительно и перегружено. Для rabbitmq и кафки, которые я должен выбрать?

Архитектура RabbitMQ

RabbitMQ — это распределенная система, и в ней есть несколько абстрактных понятий.

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

Как показано на рисунке выше, в кластере есть два узла, у каждого узла есть брокер, каждый брокер отвечает за обслуживание очереди на локальной машине, и брокеры могут взаимодействовать друг с другом. В кластере есть две очереди A и B, и каждая очередь делится на главную очередь и зеркальную очередь (резервную). Так как же реализовано производство и потребление в очереди?

потребление очереди

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

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

производство очереди

Принцип тот же, что и при потреблении: если он подключен к неглавному узлу очереди, он будет маршрутизирован.

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

Kafka

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

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

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

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

Видно, что Kafka определенно рассчитан на высокую пропускную способность.Например, если количество осколков установлено на 100, то есть 100 машин для передачи трафика темы, что, конечно, лучше, чем производительность одной машины КроликMQ.

Суммировать

В этой статье сравниваются только Kafka и RabbitMQ, но существует больше, чем эти две очереди с открытым исходным кодом, такие как ZeroMQ, RocketMQ, JMQ и т. д., и нет подробного обзора из-за ограниченного времени, поэтому он не входит в рамки этой статьи. сравнение.

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

Нижняя пропускная способность: кафка и кролика могут быть.
Высокая пропускная способность: Кафка.

Содержание этой статьи относится к официальным документам RabbitMQ и Kafka, поэтому, если вы действительно хотите понять принцип работы мидлвара, лучше всего прочитать официальные документы.В документах есть подробные схемы проектирования.Можем сравнить Схемы проектирования сами, чтобы выяснить, что подходит для нашей реальной ситуации.