Apache Kafka превратилась в платформу для создания надежных систем на основе событий с возможностью обработки сверхбольших объемов данных, поддерживаемых простым горизонтальным масштабированием. Apache Kafka - это быстрая, масштабируемая и отказоустойчивая система обмена сообщениями публикация-подписка. Он отличается высокой доступностью, устойчивостью к сбоям узлов и поддерживает автоматическое восстановление. Давайте кратко рассмотрим концепции Apache Kafka Core:

Темы: тема относится к определенному потоку данных.

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

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

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

Брокеры: кластер Kafka состоит из нескольких серверов, называемых брокерами, которые обслуживают и получают данные.

  • Каждому брокеру присваивается целочисленный идентификатор.
  • Каждый брокер содержит определенные тематические разделы, и подключение к любому брокеру подключит вас ко всему кластеру.

Фактор репликации. Фактор репликации позволяет реплицировать разделы темы на другого брокера с репликой набора данных (в идеале 3), чтобы в случае отказа одного из брокеров другой брокер все еще мог обслуживать данные. При коэффициенте репликации N производители и потребители могут терпеть отключение до N-1 брокеров.

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

ISR (синхронизированная реплика): ISR - это копии раздела, синхронизированные с лидером. Каждый раздел темы имеет одного лидера и несколько ISR в зависимости от фактора репликации.

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

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

  • Acks = 0: продюсер не будет ждать подтверждения. (Быстрая, но возможная потеря данных, подходит для малоценных данных, например журналов)
  • Acks = 1: производитель будет ждать подтверждения лидера. (ограниченная потеря данных, все еще высокая производительность)
  • Acks = all: Leader + ISRs подтверждения (без потери данных, сравнительно медленнее, также зависит от количества реплик, подходит для транзакционных данных).

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

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

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

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

Потребительские смещения: Kafka хранит смещения, по которым группа потребителей считывала и фиксирует в реальном времени в теме Kafka под названием «__consumer_offsets». Таким образом, когда потребитель умирает, он сможет читать с того места, где он остановился.

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

  • Не более одного раза: смещения фиксируются, как только сообщение получено. Если обработка пойдет не так или потребитель умрет, сообщение будет потеряно и больше не будет прочитано.
  • По крайней мере один раз. Смещения фиксируются после обработки сообщения. Итак, если обработка пойдет не так, сообщение будет прочитано снова. Это может привести к дублированию обработки сообщений, а это означает, что повторная обработка не повлияет на систему. (например, обновление базы данных, а не дублирующая вставка) (Скорее всего, используется)
  • Ровно один раз: если потребитель считывает данные и выполняет обработку, но до записи смещений, потребитель отключается, и должен произойти полный откат транзакции. (Очень сложно достичь)

Спасибо за прочтение.

Далее: https://medium.com/@navdeepsharma/the-ecosystem-of-apache-kafka-6087b621d16f