Репликация

Платформа ADS реплицирует журнал для каждой партиции топика через настраиваемое число серверов (коэффициент репликации можно задать по принципу “topic-by-topic”). Это реализует постоянный доступ к данным, выполняя автоматический переход к репликам при сбое сервера в кластере.

Другие системы обмена сообщениями предоставляют некоторые связанные с репликацией функции, но, по нашему (полностью предвзятому) мнению, они не сильно востребованы и при этом имеют большие минусы: неактивность подчиненных процессов, сильное отрицательное влияние на производительность, ручная настройка fiddly и т.д. Платформа ADS подразумевает репликацию по умолчанию – фактически нереплицируемые топики реализуются как реплицированные с коэффициентом репликации – один.

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

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

Как и в большинстве распределенных систем для автоматической обработки сбоев требуется точное определение термина “живой” узел. Для такого узла у ADS есть два условия:

  1. Узел должен иметь возможность поддержки сессии с ZooKeeper (через механизм Heartbeat ZooKeeper).
  2. Если узел является подчиненным, он должен реплицировать записи, происходящие на лидере, и не отставать “слишком далеко”.

В ADS узлы, удовлетворяющие этим двум условиям, называются “синхронизированными” во избежание неопределенности “живых” или “неисправных” узлов. Лидер отслеживает набор синхронизированных узлов и, если последователь терпит неудачу, зависает или отстает, лидер удаляет его из списка синхронизирующих реплик. Выявление зависающих и отстающих реплик контролируется конфигурацией replica.lag.time.max.ms.

В терминологии распределенных систем ADS старается обрабатывать модель “сбой/восстановление”, когда узлы внезапно прекращают работу, а затем восстанавливаются (возможно, не зная, что они потерпели неудачу). ADS не обрабатывает так называемые “византийские” сбои, когда узлы выдают произвольные или вредоносные ответы.

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

Important

Гарантия, которую оказывает ADS, заключается в том, что зафиксированное сообщение не может быть потеряно, если хотя бы одна из синхронизированных реплик остается “живой”

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