Кейс (кратко)
- Сцена: геораспределённая БД с репликами в регионах A и B. Транзакция T изменяет объекты в обоих регионах. Координатор транзакции находится в A и использует протокол $2$PC.
- Сбой: сеть между A и B частично разорвана; координатор успел отправить PREPARE в B и получил VOTE=YES, упал до записи COMMIT в журнале или до рассылки COMMIT другим участникам. B считает транзакцию подготовленной, но по таймауту некоторые участники откатили, другие — применили коммит (или напротив). В результате часть реплик видит изменения, часть — нет → рассинхронизация.
Какие «косяки» протоколов согласования могли привести
- Отсутствие устойчивой записи подготовленного состояния на диске у координатора/участников (непостоянность WAL).
- Неправильные таймауты и ретраи: агрессивный таймаут у участника приводит к авто-откату при задержке сети.
- Координаторный краш между фазами (фаза PREPARE и COMMIT) без механизма восстановления/согласования состояния.
- Отсутствие централизованного источника правды (commit decision не защищён консенсусом) — split-brain при leader election.
- Неправильная реализация идемпотентности повторных сообщений (повторный COMMIT может быть проигнорирован или применён дважды).
- Использование только $2$PC без слоя consensus (Paxos/Raft) делает систему блокирующей при partition.
- Часовые погрешности/несогласованные временные метки (clock skew) при snapshot/serializable схемах — write skew, неверные видимости снимков.
Как восстановить консистентность (пошагово, практично)
1. Обнаружение рассинхронизации: compare-checksums, anti-entropy, background repair, divergence logs.
2. Собрать журналы (WAL, prepare/commit/abort) со всех реплик для спорных транзакций.
3. Определить авторитетный источник решения:
- Если есть жёсткий commit record от координатора или кворума участников — считать решение окончательным.
- Если нет однозначного решения — перейти к разрешению конфликтов (см. ниже).
4. Применить решение:
- Если кворум подтвердил COMMIT — принудительно применить транзакцию на отставших репликах (replay idempotent записей) до достижения кворума.
- Если кворум подтвердил ABORT — откатить/компенсировать частично применённые изменения (compensating transactions).
- Если конфликта по смыслу данных — ручная или семантическая разрешающая логика (business rules).
5. Очистка подготовленных состояний (garbage collect prepare-entries) после восстановления.
6. Проверка и тесты: контрольные суммы, мониторинг, прогон антикоррупционных процедур.
Технические инструменты для восстановления
- Replaying WAL с учётом idempotency.
- Anti-entropy + Merkle trees для поиска расхождений.
- Compensating transactions (Sagas) для семантического отката.
- Использование quorum-процедур для выбора authoritative value.
Какие решения применимы и какие trade-offs
- CAP: в сетевых разрывах нужно выбирать:
- CP (Consistency + Partition tolerance) — жёсткий консенсус, отказ в обслуживании при partition, но сильная согласованность.
- AP (Availability + Partition tolerance) — разрешить локальные коммиты и решать конфликты потом (eventual consistency, CRDTs).
- Consensus (Paxos/Raft):
- Использовать Paxos/Raft для репликации и принятия commit-decisions (Paxos-commit или Raft-backed commit log). Даёт сильную согласованность и решение split-brain, но добавляет задержку при гео-распространении.
- Рекомендуется держать метаданные транзакции/координатора в консенсусном кворуме.
- Транзакции с компенсацией (Sagas):
- Для длинных распределённых операций: разбивать на шаги с компенсациями; повышает availability, но требует бизнес-логики для компенсаций.
- $2$PC vs $3$PC:
- $2$PC прост, но блокирующий при падении координатора.
- $3$PC уменьшает блокировки, но не устойчив к асинхронной сети/partition в общем случае — не популярно в реальных гео-сценариях.
- Специальные подходы:
- Spanner + TrueTime (bounded clock uncertainty $ϵ$) для глобальной внешней согласованности.
- CRDTs / last-writer-wins для разрешения конфликтов в системах, где eventual consistency допустима.
- Quorum-based writes/reads с правилом доступа $\lceil N/2\rceil$ для согласованности (например, read-quorum + write-quorum пересекаются).
- Практические рекомендации:
- Использовать консенсус (Raft/Paxos) для commit-логики или хранить статус prepare/commit в кворуме.
- Держать prepare/commit записи на диске (WAL) у участников и координатора.
- Делать операции идемпотентными, аккуратно настраивать таймауты и ретраи.
- Где возможно — применять Sagas для распределённых бизнес-транзакций.
- Вводить мониторинг divergence, автоматический anti-entropy и инструменты для ручной reconciliation.
Коротко: причина рассинхронизации — частые ошибки в управлении подготовленным состоянием, таймаутах и отсутствии консенсуса для commit-decision. Восстановление = обнаружение расхождений → выбор авторитетного решения через логи/кворум → применение или компенсация изменений → очистка. Для надёжности предпочесть consensus-протоколы (Paxos/Raft) или Sagas/CRDTs в зависимости от требований CAP.