Глубокое погружение в архитектуру Kafka: от простых сценариев до геокластера

[npu1gh0st]

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

Объективные недочёты: в секции про Partitioner текст дублируется по 2 раза.

Имхо недочёты: за пределами основ, уже нет той приятной детальности, если тестирование ещё хоть как-то вписывается в статью, то георепликация жутко выбивается, описана слишком поверхностно, графика уже не столь удачна. К примеру в графике репликации active-active требует нанесение не только ЦОДов и Брокеров, но и отдельных Кластеров Kafka, так как не очевидно, что Broker A1, B1 - это два разных кластера Kafka. Также не хватает пояснений, для чего все консьюмеры не переведены в B1, а какие-то продолжают читать из А1.

[akomiagin]

Спасибо за обратную связь и объективные замечания!

1. Убрал дублирование в разделе про Partitioner 

2. Лаконичность в разделе про георепликацию обусловлена четкими рамками выступления (время ограничено 30 минутами) на SHL++. Постараюсь внести детали в этот раздел в ближайшее время, т.к. в статье у нас таких ограничений нет.

[Vexorian]

Статья любопытная, но есть несколько неточностей.

• Consumer может читать из реплики, и уже давно. Replica.selector.class

• In flight requests per connection не отменяет гарантии по порядку, enable.idempotence = true, при условии, что acks = all /-1

• Тест с компрессией. Вообще не очень полон, если не понятно какие данные мы используем. Если не использовать батчинг, компрессия также используется, даже для одного сообщения. С не очень давних пор, можно задать уровень компрессии. Имхо, я голосую за zstd

• Конфигурация кластера интересно, но не хватает подробностей по количеству брокеров и их ролей при использовании kraft

Также хотелось бы узнать ваше мнение на тему queues in Kafka(cooperative consumers). Приходилось ли использовать и какие ожидания?

[akomiagin]

1. Спасибо за обратную связь, сценарий чтения с реплики, на мой взгляд, актуален в очень малом количестве задач, учитывая все артефакты. Поэтому не стал акцентировать внимание на Replica.selector.class.

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

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

4. Речь про https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A+Queues+for+Kafka Да, это интересная фича. Планируем использовать

5. Меня самого больше радует новый быстрый протокол ребаланса https://cwiki.apache.org/confluence/display/KAFKA/KIP-848%3A+The+Next+Generation+of+the+Consumer+Rebalance+Protocol

[Vexorian]

Спасибо за ответ!

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

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

Я думаю на 2.6 порядок ещё может нарушаться

[akomiagin]

Немного дополню свой ответ в части Replica Selector, который был добавлен в рамках https://cwiki.apache.org/confluence/display/KAFKA/KIP-392

Основной упор в этой доработке был сделан все таки для топологии гео-кластера. Т.е. основной упор там на реализацию лучшей поддержки rack awareness - RackAwareReplicaSelector.