Дизайн Kafka, репликация

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

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

Единицей репликации является раздел темы. В условиях отсутствия сбоя каждый раздел в Kafka имеет одного лидера и ноль или более последователей. Общее количество реплик, включая лидера, составляет фактор репликации. Все операции чтения и записи переходят к лидеру раздела. Обычно разделов намного больше, чем брокеров, и лидеры равномерно распределяются между брокерами. Журналы последователей идентичны журналу лидера - все они имеют одинаковые смещения и сообщения в одном порядке (хотя, конечно, в любой момент времени у лидера может быть несколько еще не реплицированных сообщений в конце своего журнала).

Последователи принимают сообщения от лидера, как обычный потребитель Kafka, и применяют их в своем собственном журнале. То, что последователи оттягивают от лидера, имеет приятное свойство, позволяющее подписчику естественным образом объединять записи журнала, которые они применяют к своему журналу.

Как и в случае с большинством распределенных систем, автоматическая обработка сбоев требует точного определения того, что означает «работоспособность» узла. Для живучести узла Kafka есть два условия

• Узел должен иметь возможность поддерживать сеанс с ZooKeeper (через механизм heartbeat ZooKeeper)
• Если это ведомый, он должен копировать записи, происходящие на лидере, и не отставать "слишком далеко".

Узлы, удовлетворяющие этим двум условиям, называют «синхронизированными» (in sync), чтобы избежать неопределенности между «живым» (alive) или «неисправным» (failed). Лидер отслеживает набор «синхронизированных» узлов. Если последователь умирает, застревает или отстает, лидер удаляет его из списка синхронизируемых реплик. Определение зависших и отстающих реплик контролируется конфигурацией replica.lag.time.max.ms.

В терминологии распределенных систем Kafka пытается справиться только с моделью сбоя/восстановления, когда узлы внезапно перестают работать, а затем восстанавливаются (возможно, не зная, что они умерли). Kafka не обрабатывает так называемые «византийские» сбои ("Byzantine" failures), при которых узлы производят произвольные или злонамеренные ответы (возможно, из-за ошибок или нечестной игры).

Теперь мы можем более точно определить, что сообщение считается зафиксированным, когда все синхронизированные реплики для этого раздела применили его к своему журналу. Потребителю выдаются только зафиксированные сообщения. Это означает, что потребителю не нужно беспокоиться о том, что он потенциально может увидеть сообщение, которое может быть потеряно в случае отказа лидера. Производители, с другой стороны, имеют возможность либо ждать, пока сообщение будет зафиксировано, либо нет, в зависимости от их предпочтения в отношении компромисса между задержкой и долговечностью. Это предпочтение контролируется настройкой acks, которую использует производитель. Обратите внимание, что в темах есть настройка «минимального количества» синхронизированных реплик, которая проверяется, когда производитель запрашивает подтверждение того, что сообщение было записано в полный набор синхронизированных реплик. Если производитель запрашивает менее строгое подтверждение, то сообщение может быть зафиксировано и использовано, даже если количество синхронизируемых реплик меньше минимального (например, оно может быть таким низким, как просто наличие сообщения у лидера).

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

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

---

Читайте также:

• Дизайн Kafka, потребитель (Consumer)
• Дизайн Kafka, потребитель (Consumer), позиция потребителя
• Дизайн Kafka, семантика доставки сообщений