Отказоустойчивая Kafka-очередь
Как на уровне Kafka/очереди рассуждать про replication, min.insync.replicas, acknowledgements и CAP trade-off, если нужно не терять сообщения при отказах?
Короткий ответ
Нужно выбрать replication factor, min.insync.replicas и producer acks так, чтобы commit считался успешным только после записи в достаточное число реплик. При этом latency и availability ухудшаются.
Полный разбор
Для Kafka важно разделять partition leader, follower replicas, ISR и producer acknowledgements. Если producer пишет с acks=all, а topic настроен с replication.factor=3 и min.insync.replicas=2, сообщение считается подтвержденным только когда оно попало минимум в две синхронные реплики. Это снижает риск потери при падении leader-а.
Но это trade-off: чем строже consistency, тем выше latency и тем чаще запись может быть недоступна при деградации реплик. Если min.insync.replicas слишком низкий или producer использует acks=1, можно получить успешный ack от leader-а и потерять сообщение при его падении до репликации.
Для двух дата-центров нужно отдельно обсуждать размещение replicas, сетевые partition-и, кто принимает write traffic, допустимую задержку между ДЦ и сценарий потери целого ДЦ. Нельзя просто сказать "шесть нод" без объяснения, как они распределены и какой отказ система выдерживает.
Теория
Очередь не становится отказоустойчивой от самого факта наличия брокера. Гарантии задаются replication, quorum/ISR, producer acks и failure model.
Типичные ошибки
- Путать число consumers с надежностью хранения сообщений.
- Не связывать acks=all с min.insync.replicas.
- Не обсуждать меж-ДЦ latency и network partition.
Как отвечать на собеседовании
- Назови пример replication.factor=3, min.insync.replicas=2, acks=all.
- Обязательно проговори цену: latency и availability.