Kafka astondevs.ru

1.

Kafka
astondevs.ru

2.

3.

4. Zookeeper

Небольшая БД, которая быстро работает на чтение, но не очень быстро на запись.

5. Что представляют из себя сообщения

6. Topics (темы). Partitions (разделы).

7. Схемы

8. Где хранятся данные топика

Внутри этих подпапок лежат три файла с расширениями:
-- .log
.index
- .timeindex

9.

Сегменты

10. Брокер

- прием сообщений
- хранение сообщений
- выдача сообщений

11. Кафка кластер

12. Replications. Надежность данных и отказоустойчивость.

13. Master-Slave. Гарантия согласованности данных.

14.

15. Консьюмер. Использует команду poll()

Консьюмер получает пачку сообщений за
раз.
Порядок операций:
- fetch metadata из зукипера
- подключаемся к партициям - лидерам
- потребляем данные из партиций.

16. Одна группа потребителей с четырьмя разделами

Одна группа потребителей с четырьмя разделами

17. Четыре раздела разбиты по двум потребителям в группе

Четыре раздела разбиты по двум потребителям в группе

18. Четыре потребителя в группе, по одному разделу на каждого

Четыре потребителя в группе, по одному разделу на каждого

19. Потребителей в группе больше, чем разделов, поэтому часть из них простаивает

Потребителей в группе больше, чем разделов, поэтому
часть из них простаивает

20. Добавление новой группы потребителей

21.

22. Consumer Offset

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

23. Давайте кратко рассмотрим проблемы потери и дублирования данных

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

24. at-most-once (не более одного раза) — сообщение будет доставлено получателю не более одного раза, но может не быть доставлено

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

25. Включить семантику “Максимум один раз”

Чтобы включить семантику “Максимум один раз” в Kafka, нам нужно установить для
“enable.auto.commit” значение "true" у потребителя.

26. at-least-once (по крайней мере, один раз) — сообщение будет доставлено как минимум один раз, но возможно дублирование данных в

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

27.

Как обеспечить семантику "хотя бы один раз"
Чтобы избежать дублирования, Kafka внедрил функцию idempotent producer.
По сути, чтобы включить семантику "хотя бы один раз" в Kafka, нам нужно:
- установите для свойства “ack” значение “1” на стороне производителя
- установите для свойства “enable.auto.commit” значение “false" на стороне потребителя.
- установите для свойства “enable.idempotence” значение “true“.
- прикрепите порядковый номер и идентификатор производителя к каждому сообщению от производителя.
Kafka Broker может идентифицировать дублирование сообщений по теме, используя порядковый номер и
идентификатор производителя.

28.

exactly-once (ровно один раз) — подход, при котором сообщение доставляется
получателю строго один раз, без дублирования и потери данных.
Эта гарантия доставки аналогична семантике "по крайней мере один раз".
Сначала обрабатывается полученное событие, а затем результаты где-то сохраняются.

29.

Как обеспечить семантику «строго один раз»
- включите функцию idempotent producer и transactional в producer, установив уникальное значение “transaction.id” для
каждого производителя;
- включите функцию транзакции у потребителя, установив для свойства “isolation.level” значение “read_committed“.
Мы можем устранить дублирование в семантике "ровно один раз", используя режимы:
Идемпотентные обновления.
Мы сохраним результаты с сгенерированным уникальном идентификатором. В случае дублирования сгенерированный
идентификатор уже будет в результатах (например, в базе данных), поэтому потребитель может удалить дубликат без
обновления результатов.
Транзакционные обновления.
Производитель записывает сообщения брокеру пакетами, если эта запись завершается неудачей и производитель
повторяет попытку, сообщения в пакете могут быть записаны в Kafka более одного раза.
При отправке сообщений Kafka теперь поддерживает транзакции при отправке пачки (batch) сообщений в несколько
разделов (partition) одного топика, следуя принципу «все или ничего».
Отправленные в топик сообщения из пачки будут видны потребителю (consumer) только при успешной отправке всех
сообщений в транзакции.
А в случае ошибки транзакция считается отмененной и потребители не получат тех сообщений, которые были частично
отправлены.
Мы сохраним результаты пакетами, которые требуют запуска транзакции и фиксации транзакции.

30.

31. Демонстрация Кафки

https://softwaremill.com/kafka-visualisation/