Спроектируй распределённую систему очередей сообщений, похожую на Apache Kafka, решив следующие архитектурные компоненты: организация кластера брокеров, стратегия партиционирования топиков для оптимизации пропускной способности, координация групп консьюмеров для параллельной обработки сообщений, механизмы репликации данных для отказоустойчивости и долговечности, управление offset'ами для возможности повторного воспроизведения сообщений, гарантии упорядочивания сообщений для каждой партиции, гарантии семантики доставки (at-least-once, at-most-once и exactly-once), политики хранения и очистки сообщений, а также методы оптимизации производительности для работы с высокообъёмными операциями записи.

Организация кластера Broker

Кластер использует controller node (через ZooKeeper или KRaft) для управления leader election и метаданными. Каждый broker отвечает за лидерство определённых партиций, распределяя нагрузку по кластеру.

Стратегия партиционирования топиков

Топики разбиваются на партиции для обеспечения параллелизма. Сообщения маршрутизируются с помощью:

• hash(key) % partition_count для упорядочивания по ключу
• Round-robin для сообщений без ключа

Больше партиций — выше throughput, но увеличивается overhead координации.

Координация consumer group

Каждая партиция назначается ровно одному consumer внутри группы, что позволяет параллельную обработку. Group coordinator broker управляет rebalancing, когда consumers присоединяются или покидают группу.

Репликация данных

Каждая партиция имеет одного leader и настраиваемое количество followers (реплик). Записи идут в leader; followers синхронизируются асинхронно. Параметры replication.factor и min.insync.replicas контролируют гарантии durability.

Управление оффсетами

Оффсеты consumer'ов хранятся во внутреннем топике (__consumer_offsets). Это позволяет:

• Переигрывать сообщения путём сброса оффсетов
• Независимо отслеживать прогресс каждого consumer

Порядок сообщений

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

Семантики доставки

• At-most-once — коммитим оффсет перед обработкой; возможна потеря сообщений
• At-least-once — коммитим после обработки; возможны дубликаты
• Exactly-once — достигается через idempotent producers и transactional APIs (enable.idempotence=true, isolation.level=read_committed)

Политики хранения

Сообщения сохраняются на основе:

• Времени — retention.ms
• Размера — retention.bytes
• Compaction — сохраняет только последнее значение для каждого ключа

Оптимизация производительности

• Батчинг записей с помощью linger.ms и batch.size
• Последовательная запись на диск через append-only log segments
• Zero-copy transfers через sendfile() syscall
• Сжатие с snappy или lz4