Partition kafka что это

Практический взгляд на хранение в Kafka

Оригинал статьи на английском
Kafka повсюду. Где есть микросервисы и распределенные вычисления, а они сейчас популярны, там почти наверняка есть и Kafka. В статье я попытаюсь объяснить, как в Kafka работает механизм хранения.

Я, конечно, постарался не усложнять, но копать будем глубоко, поэтому какое-то базовое представление о Kafka не помешает. Иначе не все будет понятно. В общем, продолжайте читать на свой страх и риск.

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

С основной теорией мы определились, давайте перейдем к практике.

Я создам в Kafka топик с тремя партициями. Если хотите повторять за мной, вот как выглядит команда для локальной настройки Kafka в Windows.

kafka-topics.bat —create —topic freblogg —partitions 3 —replication-factor 1 —zookeeper localhost:2181

В каталоге журналов Kafka создано три каталога:

Мы создали в топике три партиции, и у каждой — свой каталог в файловой системе. Еще тут есть несколько файлов (index, log и т д.), но о них чуть позже.

Обратите внимание, что в Kafka топик — это логическое объединение, а партиция — фактическая единица хранения. То, что физически хранится на диске. Как устроены партиции?

Партиции

В теории партиция — это неизменяемая коллекция (или последовательность) сообщений. Мы можем добавлять сообщения в партицию, но не можем удалять. И под «мы» я подразумеваю продюсеров в Kafka. Продюсер не может удалять сообщения из топика.

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

$ ls -lh freblogg-0
total 20M
— freblogg 197121 10M Aug 5 08:26 00000000000000000000.index
— freblogg 197121 0 Aug 5 08:26 00000000000000000000.log
— freblogg 197121 10M Aug 5 08:26 00000000000000000000.timeindex
— freblogg 197121 0 Aug 5 08:26 leader-epoch-checkpoint

Как видите, файлы index вместе весят 20 МБ, а файл log совершенно пустой. В папках freblogg-1 и freblogg-2 то же самое.
Давайте отправим сообщения через console producer и посмотрим, что будет:

kafka-console-producer.bat —topic freblogg —broker-list localhost:9092

Я отправил два сообщения — сначала ввел стандартное «Hello World», а потом нажал на Enter, и это второе сообщение. Еще раз посмотрим на размеры файлов:

$ ls -lh freblogg*
freblogg-0:
total 20M
— freblogg 197121 10M Aug 5 08:26 00000000000000000000.index
— freblogg 197121 0 Aug 5 08:26 00000000000000000000.log
— freblogg 197121 10M Aug 5 08:26 00000000000000000000.timeindex
— freblogg 197121 0 Aug 5 08:26 leader-epoch-checkpoint

freblogg-1:
total 21M
— freblogg 197121 10M Aug 5 08:26 00000000000000000000.index
— freblogg 197121 68 Aug 5 10:15 00000000000000000000.log
— freblogg 197121 10M Aug 5 08:26 00000000000000000000.timeindex
— freblogg 197121 11 Aug 5 10:15 leader-epoch-checkpoint

freblogg-2:
total 21M
— freblogg 197121 10M Aug 5 08:26 00000000000000000000.index
— freblogg 197121 79 Aug 5 09:59 00000000000000000000.log
— freblogg 197121 10M Aug 5 08:26 00000000000000000000.timeindex
— freblogg 197121 11 Aug 5 09:59 leader-epoch-checkpoint

Два сообщения заняли две партиции, и файлы log в них теперь имеют размер. Это потому, что сообщения в партиции хранятся в файле xxxx.log. Давайте заглянем в файл log и убедимся, что сообщение и правда там.

Файлы с форматом log не очень удобно читать, но мы все же видим в конце «Hello World», то есть файл обновился, когда мы отправили сообщение в топик. Второе сообщение мы отправили в другую партицию.

Обратите внимание, что первое сообщение попало в третью партицию (freblogg-2), а второе — во вторую (freblogg-1). Для первого сообщения Kafka выбирает партицию произвольно, а следующие просто распределяет по кругу (round-robin). Если мы отправим третье сообщение, Kafka запишет его во freblogg-0 и дальше будет придерживаться этого порядка. Мы можем и сами выбирать партицию, указав ключ. Kafka хранит все сообщения с одним ключом в одной и той же партиции.

Каждому новому сообщению в партиции присваивается Id на 1 больше предыдущего. Этот Id еще называют смещением (offset). У первого сообщения смещение 0, у второго — 1 и т. д., каждое следующее всегда на 1 больше предыдущего.

Давайте используем инструмент Kafka, чтобы понять, что это за странные символы в файле log. Нам они кажутся бессмысленными, но для Kafka это метаданные каждого сообщения в очереди. Выполним команду:

kafka-run-class.bat kafka.tools.DumpLogSegments —deep-iteration —print-data-log —files logs\freblogg-2\00000000000000000000.log

umping logs\freblogg-2\00000000000000000000.log
Starting offset: 0

offset: 0 position: 0 CreateTime: 1533443377944 isvalid: true keysize: -1 valuesize: 11 producerId: -1 headerKeys: [] payload: Hello World

offset: 1 position: 79 CreateTime: 1533462689974 isvalid: true keysize: -1 valuesize: 6 producerId: -1 headerKeys: [] payload: amazon

(Я удалил из выходных данных кое-что лишнее.)

Здесь мы видим смещение, время создания, размер ключа и значения, а еще само сообщение (payload).

Надо понимать, что партиция привязана к брокеру. Если у нас, допустим, три брокера, а папка freblogg-0 существует в broker-1, в других брокерах ее не будет. У одного топика могут быть партиции в нескольких брокерах, но одна партиция всегда существует в одном брокере Kafka (если установлен коэффициент репликации по умолчанию 1, но об этом чуть позже).

Сегменты

Что это за файлы index и log в каталоге партиции? Партиция, может, и единица хранения в Kafka, но не минимальная. Каждая партиция разделена на сегменты, то есть коллекции сообщений. Kafka не хранит все сообщения партиции в одном файле (как в файле лога), а разделяет их на сегменты. Это дает несколько преимуществ. (Разделяй и властвуй, как говорится.)

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

Нули (00000000000000000000) в файлах log и index в каждой папке партиции — это имя сегмента. У файла сегмента есть файлы segment.log, segment.index и segment.timeindex.

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

В имени каждого файла сегмента отражается смещение от первого сообщения. На картинке выше в сегменте 0 содержатся сообщения со смещением от 0 до 2, в сегменте 3 — от 3 до 5, и так далее. Последний сегмент, шестой, сейчас активен.

У нас всего по одному сегменту в каждой партиции, поэтому они называются 00000000000000000000. Раз других файлов сегментов нет, сегмент 00000000000000000000 и будет активным.

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

Допустим, мы отправили в партицию freblogg-2 три сообщения, и она выглядит так:

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

Удивительное дело, но новый сегмент называется не 01. Мы видим 03.index, 03.log. Почему так?

Kafka называет сегмент по имени минимального смещения в нем. Новое сообщение в партиции имеет смещение 3, поэтому Kafka так и называет новый сегмент. Раз у нас есть сегменты 00 и 03, мы можем быть уверены, что сообщения со смещениями 0, 1 и 2 и правда находятся в сегменте 00. Новые сообщения в партиции freblogg-2 со смещениями 3 ,4 и 5 будут храниться в сегменте 03.

В Kafka мы часто читаем сообщения по определенному смещению. Искать смещение в файле log затратно, особенно если файл разрастается до неприличных размеров (по умолчанию это 1 ГБ). Для этого нам и нужен файл .index. В файле index хранятся смещения и физическое расположение сообщения в файле log.

Файл index для файла log, который я приводил в кратком отступлении, будет выглядеть как-то так:

Если нужно прочитать сообщение со смещением 1, мы ищем его в файле index и видим, что его положение — 79. Переходим к положению 79 в файле log и читаем. Это довольно эффективный способ — мы быстро находим нужное смещение в уже отсортированном файле index с помощью бинарного поиска.

Параллелизм в партициях

Чтобы гарантировать порядок чтения сообщений из партиции, Kafka дает доступ к партиции только одному консюмеру (из группы консюмеров). Если партиция получает сообщения a, f и k, консюмер читает их в том же порядке: a, f и k. Это важно, ведь порядок потребления сообщений на уровне топика не гарантирован, если у вас несколько партиций.

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

Топики

Наконец, переходим к топикам. Мы уже кое-что знаем о них. Главное, что нужно знать: топик — это просто логическое объединение нескольких партиций.

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

Репликация

Как работает репликация? Создавая топик в Kafka, мы указываем для него коэффициент репликации — replication-factor. Допустим, у нас два брокера и мы устанавливаем replication-factor 2. Теперь Kafka попытается всегда создавать бэкап, или реплику, для каждой партиции в топике. Kafka распределяет партиции примерно так же, как HDFS распределяет блоки данных по нодам.

Допустим, для топика freblogg мы установили коэффициент репликации 2. Мы получим примерно такое распределение партиций:

Даже если реплицированная партиция находится в другом брокере, Kafka не разрешает ее читать, потому что в каждом наборе партиций есть LEADER, то есть лидер, и FOLLOWERS — ведомые, которые остаются в резерве. Ведомые периодически синхронизируются с лидером и ждут своего звездного часа. Когда лидер выйдет из строя, один из in-sync ведомых будет выбран новым лидером, и вы будете получать данные из этой партиции.

Лидер и ведомый одной партиции всегда находятся в разных брокерах. Думаю, не нужно объяснять, почему.

Мы подошли к концу этой длинной статьи. Если вы добрались до этого места — поздравляю. Теперь вы знаете почти все о хранении данных в Kafka. Давайте повторим, чтобы ничего не забыть.

Итоги

В Kafka данные хранятся в топиках.
Топики разделены на партиции.
Каждая партиция разделена на сегменты.
У каждого сегмента есть файл log, где хранится само сообщение, и файл index, где хранится позиция сообщения в файле log.
У одного топика могут быть партиции в разных брокерах, но сама партиция всегда привязана к одному брокеру.
Реплицированные партиции существуют пассивно. Вы обращаетесь к ним, только если сломался лидер.

Ваша Kafka, сэр!

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

Для начала отметим, что автор является абсолютным экспертом в этой области и его мнение является правдой в последней инстанции.

Apache Kafka — это так называемая “Distributed Streaming Platform” или по-русски распределенная система передачи сообщений, рассчитанная на высокую пропускную способность. Спроектирована и реализована эта платформа на не менее эзотерическом языке Scala. Главные достоинства Apache Kafka:

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

Определимся с терминологией:

Producer — процесс/молодой человек/приложение, которое производит сообщения;
Consumer — процесс, который читает эти сообщения;
Topic — основная абстракция Apache Kafka. Это место, в котором хранятся все эти записи, каждый топик состоит из Partition.
Partition — следующий уровень абстракции, который основан на разбиении каждого топика на 1, 2 и более частей. Каждое сообщение, находящееся в любом из partition, имеет так называемый offset.
Offset, порядковый номер сообщения в partition. Тут полная аналогия с памятью, чем меньше offset , тем старше сообщение.

После того мы узнали все об Apache Kafka, кхе-кхе, мы решили приступить к делу и сразу столкнулись лицом к лицу с огромным мануалом по установке. Закатив глаза, мы погуглили и нашли магический docker-файл. В итоге 6 степов и овер 20 CLI команд для установки превратились в краткое и до боли знакомое:

Итак, теперь у нас появлиась работающая Apache Kafka, но нет самого главного — задачи. Мы решили, что самым логичным и правильным применением этой масштабируемой и распределенной платформы будет передача файлов ¯\_(ツ)_/¯.

Достав из ножен свеженький Node.js v7.6.0, мы принялись считывать/передавать/записывать. Создаем 3 файла producer.js, consumer.js, test.pdf. Начнем с producer.js. Главный ингредиент — это, конечно же, клиент для Apache Kafka. После того, как мы его установили с помощью богоугодного yarn, необходимо настроить подключение:

Чтобы убедится в том, что мы все сделали верно, мы добавили в наш код console.log(), который поведает нам о состоянии topic, к которому мы подключились:

Теперь разберемся с тем, как мы будем считывать файл. Чтобы привести все данные к единому формату, будем использовать формат base64:

Настало время смешать, но не взбалтывать, Apache Kafka. И
нашу файловую систему, и не забудьте приправить все это обработчиком
ошибок:

Охапка дров и Producer готов! Теперь определимся с Consumer’ом, который будет все это дело считывать и бережно записывать к вам на жесткий диск. Порядок действий тот же, что и с Producer’ом :

Перейдем к записи на диск:

И наконец-то мы можем запустить наш код и порадоваться тем безграничным возможностям, которые нам подарили ребята из Apache Foundation.

Спасибо за внимание! Следующий шабаш состоится 11.03.2017, на котором с нами поделятся опытом 2 лучших верстальщика города Минска.

Лайк! Репост! Подписка!

Apache Kafka: основы технологии

У Kafka есть множество способов применения, и у каждого способа есть свои особенности. В этой статье разберём, чем Kafka отличается от популярных систем обмена сообщениями; рассмотрим, как Kafka хранит данные и обеспечивает гарантию сохранности; поймём, как записываются и читаются данные.

Статья подготовлена на основе открытого занятия из видеокурса по Apache Kafka. Авторы — Анатолий Солдатов, Lead Engineer в Авито, и Александр Миронов, Infrastructure Engineer в Stripe. Базовые темы курса доступны на Youtube.

Базовые компоненты классической системы очередей

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

Консьюмеры получают данные с сервера, используя две разные модели запросов: pull или push.

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

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

Как правило, приложение пишет и читает из очереди с помощью нескольких инстансов продюсеров и консьюмеров. Это позволяет эффективно распределить нагрузку.

Типичный жизненный цикл сообщений в системах очередей:

Продюсер отправляет сообщение на сервер.
Консьюмер фетчит (от англ. fetch — принести) сообщение и его уникальный идентификатор сервера.
Сервер помечает сообщение как in-flight. Сообщения в таком состоянии всё ещё хранятся на сервере, но временно не доставляются другим консьюмерам. Таймаут этого состояния контролируется специальной настройкой.
Консьюмер обрабатывает сообщение, следуя бизнес-логике. Затем отправляет ack или nack-запрос обратно на сервер, используя уникальный идентификатор, полученный ранее — тем самым либо подтверждая успешную обработку сообщения, либо сигнализируя об ошибке.
В случае успеха сообщение удаляется с сервера навсегда. В случае ошибки или таймаута состояния in-flight сообщение доставляется консьюмеру для повторной обработки.

Типичный жизненный цикл сообщений в системах очередей

С базовыми принципами работы очередей разобрались, теперь перейдём к Kafka. Рассмотрим её фундаментальные отличия.

Как и сервисы обработки очередей, Kafka условно состоит из трёх компонентов:

1) сервер (по-другому ещё называется брокер),
2) продюсеры — они отправляют сообщения брокеру,
3) консьюмеры — считывают эти сообщения, используя модель pull.

Базовые компоненты Kafka

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

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

Теперь давайте посмотрим, как Kafka и системы очередей решают одну и ту же задачу. Начнём с системы очередей.

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

1) отправить письмо пользователю,
2) пересчитать дневную статистику регистраций.

В случае с RabbitMQ или Amazon SQS функционал может помочь нам доставить сообщения всем сервисам одновременно. Но при необходимости подключения нового сервиса придётся конфигурировать новую очередь.

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

Kafka также позволяет тривиально подключать новые сервисы к стриму регистрации. Например, сервис архивирования всех регистраций в S3 для последующей обработки с помощью Spark или Redshift можно добавить без дополнительного конфигурирования сервера или создания дополнительных очередей.

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

Структура данных

Наверняка возникает вопрос: «Раз сообщения не удаляются, то как тогда гарантировать, что консьюмер не будет читать одни и те же сообщения (например, при перезапуске)?».

Для ответа на этот вопрос разберёмся, какова внутренняя структура Kafka и как в ней хранятся сообщения.

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

Например:

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

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

Для гарантии сохранности данных каждая партиция в Kafka может быть реплицирована n раз, где n — replication factor. Таким образом гарантируется наличие нескольких копий сообщения, хранящихся на разных брокерах.

У каждой партиции есть «лидер» (Leader) — брокер, который работает с клиентами. Именно лидер работает с продюсерами и в общем случае отдаёт сообщения консьюмерам. К лидеру осуществляют запросы фолловеры (Follower) — брокеры, которые хранят реплику всех данных партиций. Сообщения всегда отправляются лидеру и, в общем случае, читаются с лидера.

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

Основная структура данных в Kafka — это распределённый, реплицируемый лог. Каждая партиция — это и есть тот самый реплицируемый лог, который хранится на диске. Каждое новое сообщение, отправленное продюсером в партицию, сохраняется в «голову» этого лога и получает свой уникальный, монотонно возрастающий offset (64-битное число, которое назначается самим брокером).

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

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

Consumer Groups

Теперь давайте перейдём к консьюмерам и рассмотрим их принципы работы в Kafka. Каждый консьюмер Kafka обычно является частью какой-нибудь консьюмер-группы.

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

Вернёмся к нашему примеру с топиком сервиса регистрации и представим, что у сервиса отправки писем есть своя собственная консьюмер-группа с одним консьюмером
c1
внутри. Значит, этот консьюмер будет получать сообщения из всех партиций топика.

Если мы добавим ещё одного консьюмера в группу, то партиции автоматически распределятся между ними, и
c1
теперь будет читать сообщения из первой и второй партиции, а
c2
— из третьей. Добавив ещё одного консьюмера (c3), мы добьёмся идеального распределения нагрузки, и каждый из консьюмеров в этой группе будет читать данные из одной партиции.

А вот если мы добавим в группу ещё одного консьюмера (c4), то он не будет задействован в обработке сообщений вообще.

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

Если консьюмеры не справляются с текущим объёмом данных, то следует добавить новую партицию в топик. Только после этого консьюмер c4 начнёт свою работу.

Механизм партиционирования является нашим основным инструментом масштабирования Kafka. Группы являются инструментом отказоустойчивости.
Кстати, как вы думаете, что будет, если один из консьюмеров в группе упадёт? Совершенно верно: партиции автоматически распределятся между оставшимися консьюмерами в этой группе.

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

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

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

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

А теперь, зная внутреннее устройство консьюмеров в Kafka, давайте вернёмся к изначальному вопросу: «Каким образом мы можем обозначить сообщения в партиции, как обработанные?».

Для этого Kafka предоставляет механизм консьюмер-офсетов. Как мы помним, каждое сообщение партиции имеет свой собственный, уникальный, монотонно возрастающий офсет. Именно этот офсет и используется консьюмерами для сохранения партиций.

Консьюмер делает специальный запрос к брокеру, так называемый offset-commit с указанием своей группы, идентификатора топик-партиции и, собственно, офсета, который должен быть отмечен как обработанный. Брокер сохраняет эту информацию в своём собственном специальном топике. При рестарте консьюмер запрашивает у сервера последний закоммиченный офсет для нужной топик-партиции, и просто продолжает чтение сообщений с этой позиции.

В примере консьюмер в группе email-service-group, читающий партицию p1 в топике registrations, успешно обработал три сообщения с офсетами 0, 1 и 2. Для сохранения позиций консьюмер делает запрос к брокеру, коммитя офсет 3. В случае рестарта консьюмер запросит свою последнюю закоммиченную позицию у брокера и получит в ответе 3. После чего начнёт читать данные с этого офсета.

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

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

Представим, что обработка сообщения с офсетом 1 завершилась с ошибкой. Однако мы продолжили выполнение нашей программы в консьюмере и запроцессили сообщение с офсетом 2 успешно. В таком случае перед нами будет стоять выбор: какой офсет закоммитить — 1 или 3. В настоящей системе мы бы рекомендовали закоммитить офсет 3, добавив при этом функционал, отправляющий ошибочное сообщение в отдельный топик для повторной обработки (ручной или автоматической). Подобные алгоритмы называются Dead letter queue.

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

Apache ZooKeeper

В заключение нужно упомянуть об ещё одном важном компоненте кластера Kafka — Apache ZooKeeper.

ZooKeeper выполняет роль консистентного хранилища метаданных и распределённого сервиса логов. Именно он способен сказать, живы ли ваши брокеры, какой из брокеров является контроллером (то есть брокером, отвечающим за выбор лидеров партиций), и в каком состоянии находятся лидеры партиций и их реплики.

В случае падения брокера именно в ZooKeeper контроллером будет записана информация о новых лидерах партиций. Причём с версии 1.1.0 это будет сделано асинхронно, и это важно с точки зрения скорости восстановления кластера. Самый простой способ превратить данные в тыкву — потеря информации в ZooKeeper. Тогда понять, что и откуда нужно читать, будет очень сложно.

В настоящее время ведутся активные работы по избавлению Kafka от зависимости в виде ZooKeeper, но пока он всё ещё с нами (если интересно, посмотрите на Kafka improvement proposal 500, там подробно расписан план избавления от ZooKeeper).

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

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

Apache Kafka: что это и как работает

Apache Kafka — это система обмена сообщениями с открытым исходным кодом, которая была создана в LinkedIn примерно в 2011 году. Она обеспечивает быстрый, хорошо масштабируемый и надежный обмен сообщениями по модели pub-sub. Kafka допускает большое количество клиентов, отличается высокой доступностью, устойчивостью к сбоям узлов и поддерживает автоматическое восстановление.

Почему Apache Kafka так популярна?

Масштабируемость

Apache Kafka имеет распределенную архитектуру, обрабатывающую входящие сообщения с большим объемом и скоростью. Как результат — Kafka обладает высокой масштабируемостью без каких-либо простоев.

Высокая пропускная способность

Apache Kafka может обрабатывать миллионы сообщений в секунду. Сообщения, поступающие в большом объеме или с высокой скоростью не влияют на производительность

Низкая задержка
Kafka обеспечивает очень низкую задержку передачи, которая составляет около десяти миллисекунд
Отказоустойчивость
Используя механизм репликации, Kafka обрабатывает сбои на узлах кластера без потери данных
Надежность

Apache Kafka — это распределенная платформа с очень высокой отказоустойчивостью, что делает ее очень надежной в использовании системой

Сохранность данных

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

Обработка данных в реальном времени
Архитектура Apache Kafka

Рассмотрим архитектуру Apache Kafka и взаимосвязь между различными архитектурными компонентами, чтобы точнее понять Kafka для распределенной потоковой передачи.

На курсе [ Kafka Fundamentals ] мы поможем вам изучить инструмент с нуля до уверенного пользователя на реальных задачах за 7 недель.

Компоненты Apache Kafka и ее архитектурные концепции:

1. Topic

Поток сообщений, который является частью определенной категории или названия канала, называется топиком Kafka. В Kafka данные хранятся в виде топиков. Producer записывают свои данные в топик, а consumer читает данные из этого топика

2. Broker

Кластер Kafka состоит из одного или нескольких серверов, известных как брокеры. В Kafka брокер работает как контейнер, который может содержать несколько топиков с разными partitions. Уникальный ID используется для идентификации брокера в кластере Kafka. Подключение к любому из брокеров Kafka в кластере подразумевает подключение ко всему кластеру

3. Producer

Producers в Kafka публикует сообщения в одном или нескольких топиков. Они отправляют данные в кластер Kafka

4. Consumer and Consumer

GroupConsumers читает данные из кластера Kafka. Данные, которые должны быть прочитаны Consumers, получаются от брокера. Consumer group в Kafka объединяет несколько consumers, таким образом, что каждый consumer читает часть сообщений определенного топика

5. Partition

Топик в Kafka разделен на настраиваемое количество частей, которые называются partitions. Partition разделяет топик по нескольким брокерам, таким образом снижая нагрузку на каждый отдельный сервер. Consumers могут быть объединены в consumer group, и тогда один сonsumer может получать сообщения не из всего топика, а только из некоторых его partitions, что обеспечивает распределение нагрузки на обработку сообщений

6. Partition Offset

Сообщения или записи в Kafka относятся к partition, каждой записи присваивается число — offset, чтобы определить положение в partition. Запись идентифицируется в своем partition с помощью значения offset. Offset partition имеет значение только для этого конкретного partition. Для старых записей будут меньшие значения offset, поскольку записи добавляются в конец partition

7. Replicas

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

Вы узнаете:

— Что такое messaging system
— Что включает в себя архитектура Kafka
— Методы разворачивания docker образа
— Как пользоваться Kafka CLI
— Основы Kafka API
— Области применения Kafka

+ Практический блок: создание Java producer и Java consumer

Посмотрите нашу
лекцию по Kafkа
БЕСПЛАТНУЮ

Недостатки Apache Kafka

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

В Kafka нет поддержки выбора топика по регулярным выражениям. Название топика должно быть точным (в отличие от RabbitMQ, например).

Некоторые парадигмы передачи сообщений, такие как p2p очереди и request/response сообщения не поддерживаются Kafka.

Для больших сообщений требуется сжатие и распаковка сообщений. Это влияет на пропускную способность и производительность Kafka.

Сравнение различных брокеров сообщений (сравнения Redis, Kafka, RabbitMQ)

Какой брокер когда лучше использовать?

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

Сообщения с коротким временем жизни: Redis

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

Большие объемы данных: Kafka

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

Сложная маршрутизация: RabbitMQ

RabbitMQ — более старый и зрелый брокер с множеством функций и возможностей, поддерживающий сложную маршрутизацию. Он способен поддерживать сложную маршрутизацию, даже при высокой скорости передачи сообщений (больше нескольких десятков тысяч сообщений в секунду)

Технологический стек проекта

Также нужно учитывать ваш текущий стек проекта. Если вы ищете относительно простой процесс интеграции, то не стоит добавлять еще одну очередь сообщений в проект, лучше использовать ту что уже есть.
Например, если вы используете Celery для очереди задач в своей системе поверх RabbitMQ, у вам будет проще работать с RabbitMQ, а не с Kafka, которую еще придется ставить и настраивать

Присоединяйтесь к нам в INSTAGRAM

Соглашение на обработку персональных данных

Присоединяясь к настоящему Соглашению и оставляя свои данные на Сайте Hard&Soft Skills, путем заполнения полей онлайн-заявки (оформления заказа) Пользователь:

– подтверждает, что указанные им персональные данные принадлежат лично ему; признает и подтверждает, что он внимательно и в полном объеме ознакомился с настоящим Соглашением и содержащимися в нем условиями обработки его персональных данных, указываемых им в полях онлайн заявки (регистрации) на Сайте;
– признает и подтверждает, что все положения настоящего Соглашения и условия обработки его персональных данных ему понятны;
– дает согласие на обработку Сайтом предоставляемых персональных данных в целях регистрации Пользователя на Сайте;
– выражает согласие с условиями обработки персональных данных без каких-либо оговорок и ограничений.

Пользователь дает свое согласие на обработку его персональных данных, а именно совершение действий, предусмотренных законом «О персональных данных» Республики Беларусь, и подтверждает, что, давая такое согласие, он действует свободно, своей волей и в своем интересе. Согласие Пользователя на обработку персональных данных является конкретным, информированным и сознательным.

Настоящее согласие Пользователя применяется в отношении обработки следующих персональных данных:
– фамилия, имя, отчество;
– номера телефонов;
– адресах электронной почты (E-mail);
– данные о профессиональных навыках.

Пользователь, предоставляет сервису https://hardsoftskills.by право осуществлять следующие действия (операции) с персональными данными:

– сбор, накопление и хранение данных;
– уточнение (обновление, изменение);
– использование в целях регистрации Пользователя на Сайте;
– удаление.

Указанное согласие действует бессрочно с момента предоставления данных и может быть отозвано Вами путем обращения через «‎Форму обратной связи» или по e-mail info@hardsoftskills.by .

Сайт имеет право вносить изменения в настоящее Соглашение. При внесении изменений будет указываться дата последнего обновления.
Последнее обновление: 05/04/2021

Правила оплаты и безопасность платежей

Оплата банковскими картами осуществляется через ЗАО «Альфа-Банк»
К оплате принимаются карты международных платежных систем VISA, MasterCard, платежной системы БЕЛКАРТ. Оплату также можно совершить посредством сервисов Apple Pay, Samsung Pay.
Безопасность совершения платежа обеспечивается современными методами проверки, шифрования и передачи данных по закрытым каналам связи.
Ввод данных карточки осуществляется на защищенной авторизационной странице банка. Для оплаты необходимо ввести реквизиты карточки: номер, имя держателя, срок действия и трехзначный код безопасности. Трёхзначный код безопасности (CVV2 для VISA, CVC2 для MasterCard) — это три цифры, находящиеся на обратной стороне карточки. Если карточка поддерживает технологию 3DSecure или Интернет-пароль для держателей карточек БЕЛКАРТ, Вы будете перенаправлены на страницу банка, выпустившего карточку, для ввода кода безопасности. При оплате с помощью Apple Pay выберете карту из приложения Wallet, воспользуйтесь код- паролем или иным способом аутентификации, в зависимости от того, какой способ выбран в приложении. При оформлении заказа с помощью Samsung Pay нажмите «Оплатить Samsung Pay», введите ваш Samsung Account и подтвердите покупку на вашем смартфоне (по отпечатку пальца, радужке или PIN-коду Samsung Pay).
Данные карточки передаются только в зашифрованном виде и не сохраняются на данном интернет-ресурсе.

ВОЗВРАТ ПЛАТЕЖЕЙ
При оплате банковской платежной карточкой возврат наличными денежными средствами не
допускается. Расчеты с потребителем при возврате уплаченной за товар денежной суммы, при
расторжении договора о выполнении работы (оказании услуги) осуществляются в той же форме, в которой производилась оплата товара, работы (услуги), если иное не предусмотрено соглашением сторон. Порядок возврата регулируется правилами платежных систем.
Процедура возврата товара регламентируется Законом Республики Беларусь от 9 января 2002 г. N 90-З «О защите прав потребителей».
 Потребитель вправе отказаться от товара в течение 14(четырнадцати) дней с момента
передачи ему товара;
 Потребитель вправе в одностороннем порядке отказаться от исполнения договора о
выполнении работы (оказании услуги) при условии оплаты исполнителю фактически
понесенных им расходов, если иное не предусмотрено законодательством.
 Требование потребителя об обмене либо возврате качественного товара подлежит
удовлетворению, если товар не был в употреблении, сохранены его потребительские
свойства и имеются доказательства приобретения его у данного продавца.
 Перечень непродовольственных товаров надлежащего качества, не подлежащих обмену и
возврату, утверждается Правительством Республики Беларусь.
Для возврата денежных средств на банковскую платежную карточку необходимо заполнить
«Заявление о возврате денежных средств» и отправить его по электронному адресу
info@hardsoftskills.by.
Возврат денежных средств будет осуществлен на банковскую платежную карточку в течение 7
(семи) календарных дней со дня получения «Заявление о возврате денежных средств» Компанией.
Сумма возврата будет равняться сумме покупки
Для возврата денежных средств по операциям проведенными с ошибками необходимо
обратиться с письменным заявлением и приложением чеков/квитанций,
подтверждающих ошибочное списание. Данное заявление необходимо направить по электронному адресу info@hardsoftskills.by.