Распределенная system обмена сообщениями, broker message (базовый до понимания kafka, rabbitmq)

Здравствуйте, это codeshow.
В этом классе мы изучим распределенную систему обмена сообщениями.
В системе обмена сообщениями сообщение — это данные, которыми можно обмениваться между двумя или более отношениями.
Данные здесь обычно представляют собой двоичные данные. Отправляйте и получайте данные с помощью сериализаторов, таких как json или Protocol Buffers.
С системой обмена сообщениями посередине одна сторона имеет publisher, а другая сторона имеет отношения подписчика.
publisher— это клиент, который создает сообщения и отправляет их в очереди сообщений. Отправка сообщения в очередь называется publish .
Подписчик — это клиент, который получает сообщения из очереди сообщений. Получение сообщений из очереди называется consume .
Сообщения publish publisher , а сообщения проходят через систему обмена сообщениями к подписчикам.
Сообщения всегда идут в одну сторону: от publisher в систему обмена сообщениями к подписчикам.
Для справки мы используем термины «producer» вместо «publisher » и «consumer» вместо «подписчик».
Кроме того, pub и sub используются для сокращения publisher и подписчика.

Чтобы понять отношения между publisher и подписчиком, я объясню код в качестве примера.

package main

import "time"

func main() {
    c := make(chan string)
    go pub(c)
    go sub(c)
    select {}
}

func sub(c <-chan string) {
    for {
        message := <-c
        println(message)
    }
}

func pub(c chan<- string) {
    c <- "Hello World 1"
    time.Sleep(1 * time.Second)
    c <- "Hello World 2"
    time.Sleep(1 * time.Second)
    c <- "Hello World 3"
    time.Sleep(1 * time.Second)
    c <- "Hello World 4"
    time.Sleep(24 * time.Hour)
}

В этом коде в основной функции создается канал строкового типа.
Функция pub publish символ «Hello World».
И подпрограмма выводит «Hello World», когда сообщение поступает в канал в бесконечном цикле for.
Внутри функции pub мы publish строку в канал,
Подфункция consume строку через канал.
Модуль, который consume и обрабатывает сообщения, также называется worker.

Отношения между publisher, системой обмена сообщениями и подписчиком обсуждались ранее.
В приведенном выше старом языковом коде функция pub действует как publisher, а подфункция действует как подписчик.
И вы можете думать о переменной c строкового типа канала между этим pub и sub как о системе обмена сообщениями.

Если язык не обеспечивает обмен сообщениями, как GoLanguage, это делает фреймворк.
Взяв в качестве примера Java Spring Framework, он выдает сообщения типа ApplicationEvent.
И вы можете подписаться на publish сообщения через аннотацию EventListener.
В настоящее время о системе обмена сообщениями заботится среда Spring.
Обратите внимание, что сообщения и события похожи.
Разница между ними заключается в том, что обмен сообщениями обычно хранит сообщения в хранилище под названием «Очередь», поэтому подписчики могут обрабатывать их позже, а не сразу.
События отправляются подписчикам в момент их возникновения, а события уничтожаются.

Как объяснялось выше, обмен сообщениями имеет хранилище под названием «Очередь».
Вот почему это называется очередью сообщений.

Как правило, системы обмена сообщениями предназначены для доставки и обработки сообщений в распределенной среде.
Таким образом, ни каналы языка Go, ни EventListeners Spring Framework не являются системами обмена сообщениями в ограниченном контексте.
Однако и предыдущее, и последующее следуют архитектуре, управляемой событиями, и могут рассматриваться как системы обмена сообщениями в широком смысле.

Теперь давайте рассмотрим kafka и rabbitmq, которые являются наиболее часто используемыми распределенными системами обмена сообщениями.

Во-первых, kafka и rabbitmq — это системы обмена сообщениями, работающие в распределенной среде.
Также называется broker message .

Распределенные системы обмена сообщениями обычно обеспечивают масштабируемость, высокую доступность и надежность.

1. Для масштабируемости kafka и rabbitmq могут настроить cluster.
   Это позволяет горизонтальное масштабирование за счет увеличения количества узлов.
   Пропускную способность можно увеличить за счет горизонтального масштабирования.
2. Высокая доступность означает, что система обмена сообщениями остается работоспособной, даже если некоторые узлы не работают.
3. Надежность — это надежное поведение доставки сообщений, например, отсутствие потери опубликованных сообщений и отсутствие отправки дубликатов сообщений подписчикам.

kafka и rabbitmq удовлетворяют вышеуказанным критериям как распределенные системы обмена сообщениями.

И publisher publish по одному сообщению за раз, но через систему обмена сообщениями это сообщение может быть реплицировано и доставлено в несколько queue.

Например,

kafka делит сообщения на topic.
И эта topic снова разбита на несколько partition.
А на стороне подписчика несколько worker могут использовать одно сообщение через группы consumer .

rabbitmq состоит из exchange и queue.
Обмены определяют маршрутизацию, в какие queue доставляются сообщения.
У Rabbitmq есть 4 типа обмена: прямой, разветвленный, topic и заголовки.
Сообщения могут не только пересылаться на различные биржи, но также может выполняться маршрутизация от биржи к бирже.
По сравнению с kafka, rabbitmq имеет очень гибкий и удобный дизайн маршрутизации сообщений.

Вместо этого, поскольку rabbitmq является queue , если consumer удаляет сообщение из queue , сообщение удаляется из queue.
С другой стороны, в kafka единицами хранения являются topic и partition , а не queue .
topic— это логическая единица, которая отличает сообщения, а фактически сохраняемая единица — это partition.
Кроме того, когда consumer получает сообщения из partition, он не удаляет сообщения, как queue.
Запомните конкретное offset и подпишитесь на данные после offset . Это как массив.

В этом отличие Rabbitmq может прикреплять несколько подписчиков к одной queue, а kafka может прикреплять к одному partition только одну группу consumer .

Разница между ними также заключается в разнице в хранении.
rabbitmq в основном находится в памяти , kafka— на диске.

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

Эта разница в поведении отражается в конструкции системы обмена сообщениями в зависимости от того, для чего предназначена система обмена сообщениями.
rabbit mq предназначен для организации очереди message .
Таким образом, по сравнению с kafka, очередь сообщений очень гибкая в отношении маршрутизации, создания и удаления queue .
kafka нацелена на обработку больших сообщений по сравнению с rabbitmq.
Таким образом, по сравнению с rabbitmq, он имеет более высокую производительность для массовой пакетной обработки.

Выше мы рассмотрели распределенные системы обмена сообщениями и кратко рассмотрели rabbitmq и kafka.
Мы подробнее рассмотрим kafka и rabbitmq через код.

Наконец, мы суммировали 5 причин, по которым мы используем системы обмена сообщениями.

1. Коммуникация: данные могут передаваться между publisher и подписчиком. Это освобождает вас от ограничений между разными языками, платформами и неоднородностями.
2. Асинхронный. По сравнению с синхронным обменом данными асинхронный обмен данными может повысить производительность по сравнению с процедурным обменом данными.
3. Высокая доступность. В распределенной системе обмена сообщениями нормальная работа гарантируется, даже если некоторые системы обмена сообщениями не работают, хотя производительность может снизиться.
4. Повторная попытка: даже если worker выходит из строя, сообщения остаются в queue, поэтому, если worker возвращается, он может продолжить работу после предыдущей неудачной операции. Даже при сокращении реального времени согласованность данных становится надежной.
5. Слабая связанность: благодаря косвенным вызовам через систему обмена сообщениями, а не прямым вызовам, стороне publisher не нужно знать всю бизнес-логику после публикации сообщения. Это роль publisher только до публикации. Затем сообщение доставляется абоненту через систему обмена сообщениями. Теперь за обработку сообщения отвечает подписчик. Слабая связь, достигаемая за счет косвенных, а не прямых вызовов publisher, позволяет нашему программному обеспечению быть более гибким и масштабируемым.

Настройки подписки и лайков очень полезны для создателей контента.

Спасибо