Что такое топик и партиция в Kafka

Что проверяют

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

Как отвечать

• топик: именованный логический поток сообщений, например orders. Сам по себе он ничего не хранит, данные живут в его партициях;
• партиция: упорядоченный журнал, в который сообщения только дописываются. У каждого сообщения свой offset, порядок гарантирован только внутри одной партиции;
• ключ: продюсер выбирает партицию по хэшу ключа, поэтому все сообщения с одинаковым ключом попадают в одну партицию и читаются по порядку. Без ключа сообщения раскидываются по разным партициям;
• репликация: у партиции есть лидер и реплики на других брокерах, запись идёт в лидера. replication.factor и min.insync.replicas вместе с acks=all решают, переживёт ли сообщение падение брокера;
• группа потребителей: одну партицию внутри группы читает ровно один потребитель. Отсюда потолок параллелизма: при шести партициях седьмой экземпляр сервиса будет простаивать.

Для C# покажите это на клиенте Confluent.Kafka: ProduceAsync с Message<string, T>, где ключом выступает orderId, и IConsumer с Subscribe внутри BackgroundService. Стоит упомянуть, что сообщения не удаляются после чтения: они живут по retention.ms или сжимаются по ключу при cleanup.policy=compact, а позицию чтения группа хранит в закоммиченных смещениях.

Где спотыкаются

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

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

Путают партицию с репликой и считают, что больше партиций означает больше надёжности. Надёжность даёт фактор репликации, партиции дают параллелизм.