Split-brain возникает, когда распределённая система разделяется на две или более частей, и каждая считает себя «главной». Это приводит к двойным записям, конфликтующим данным и разрушению согласованности.
Паттерн Split-Brain Avoidance использует кворум, детекторы сбоев, heartbeat, механизмы выбора лидера и политику fencing, чтобы гарантировать: только одна часть кластера может работать как активная.
Это один из важнейших паттернов для отказоустойчивых систем: от него зависит сохранность данных, корректность журналов, устойчивость к сетевым сбоям и надежная работа распределённых сервисов.
Split-brain — одна из самых опасных ситуаций в распределённых системах. Она возникает, когда между узлами произошёл сетевой разрыв, и каждый фрагмент кластера решает, что он и есть «настоящий» активный сегмент. В результате два узла (или две группы узлов) начинают одновременно выполнять операции, которые должны быть уникальными. Это приводит к конфликтам данных, нарушению инвариантов, повреждению журналов транзакций и потенциально необратимой потере целостности системы.
Чтобы понять опасность split-brain, представим простую систему с реплицированием. Если кластеры А и Б потеряли связь, и оба продолжают принимать записи, то после восстановления соединения данные оказываются несовместимыми. Придется разруливать конфликты вручную, а в некоторых случаях — терять данные. Поэтому предотвратить split-brain — задача фундаментального уровня для архитектора.
Существует несколько ключевых механизмов предотвращения split-brain, каждый из которых решает важную часть проблемы:
1. Кворум (quorum-based decisions)
Большинство узлов должны участвовать в принятии решения. Если кластер разделился, только та часть, у которой ≥ majority, сохраняет активность. Остальная автоматически становится пассивной или выключает операции записи.
2. Heartbeats и детекторы отказов
Узлы регулярно отправляют heartbeat. Если heartbeat не поступает, система считает сегмент недоступным.
Это основа корректного определения того, потерян ли узел или это просто задержка сети.
3. Выбор лидера (Leader Election)
Лидер несет ответственность за согласованность. При сетевых проблемах новый лидер выбирается только там, где есть кворум. Это предотвращает появление двух лидеров одновременно.
4. Fencing (отсечение «ложного лидера»)
Даже если старый лидер «очнулся» и считает себя активным, fencing не позволяет ему модифицировать общее состояние.
Fencing может работать через:
-
токены с monotonic counter,
-
сессионные идентификаторы,
-
generation numbers,
-
протоколы односторонней блокировки.
Это самый надежный способ предотвратить split-brain в storage-системах.
5. Stonith / Shoot-the-other-node-in-the-head
Жесткая политика отказа: если узел подозревают в несогласованности, кластер его отключает физически или логически.
Используется в HA-кластерах Linux, базах данных и гиперконвергентных системах.
Реальные промышленные системы используют комбинацию всех этих механизмов. Например:
— ZooKeeper использует majority-quorum, heartbeats и протокол Zab;
— Etcd и Consul используют Raft, где лидер выбирается через строгое большинство и с жесткой политикой логов;
— Cassandra использует кворумные записи и «hinted handoff», но избегает split-brain через централизованный gossip-protocol;
— Redis Sentinel при split-brain делает failover только при наличии кворума наблюдателей;
— Ceph, GlusterFS, HDFS — используют fencing и механизм журналирования.
В архитектуре микросервисов split-brain может возникнуть в сервисных mesh-сетях, системах кеширования, брокерах сообщений и в кластерах API Gateway.
Поэтому архитектор обязан понимать, как проектировать маршрутизацию, балансировку и хранение состояния так, чтобы исключить множественных активных лидеров.
Split-brain также связан с CAP-теоремой:
-
для предотвращения split-brain нужно выбирать C (consistency) над A (availability) в условиях разделения сети.
То есть лучше остановить часть кластера, чем позволить неконсистентные записи.
На рынке труда паттерн Split-Brain Avoidance — один из критериев компетентности архитектора распределённых систем. Специалисты, понимающие, как проектировать кворумы, fencing, failover и правила голосования, крайне востребованы в банковской сфере, телекомах, маркетплейсах, госуслугах и highload-системах.