Сценарий
- Система: распределённое key-value хранилище, шардинг по ключам, репликация каждой шарды в отдельный кластер из $N$ узлов, кластеры размещены в разных дата‑центрах.
- Сетевая проблема: разрыв каналов между дата‑центрами — часть реплик одной шарды оказывается в одном сегменте сети, часть — в другом (partition). Клиенты могут подключаться к любому дата‑центру.
Выбор протокола консенсуса
- Рекомендация: Raft для классической (не‑византийской) модели отказов — простой для реализации и понимания, обеспечивает линейную согласованность (linearizability) и отказоустойчивость.
- Если возможны византийские (злонамеренные) узлы — выбирать PBFT или его оптимизированные вариации.
Ключевые механики Raft (в контексте partition)
- Кластер держит одного лидера; все записи идут через лидера, он реплицирует log на реплики.
- Решение о применении записи принимается после получения подтверждений от кворума. Размер кворума $q=\lceil \frac{N}{2}\rceil$.
- При partition лидер, не имеющий кворума, не сможет продвинуть лог — записи не будут подтверждены, лидер уйдёт в демонстрацию выбора нового лидера (или потеряет активность). Это предотвращает split‑brain, но снижает доступность в партиционированной части.
CAP — ограничения и последствия
- CAP: нельзя одновременно гарантировать Consistency (C), Availability (A) и Partition tolerance (P) при наличии разделений сети. На практике P обязателен (сеть ненадёжна), значит при partition приходится выбирать между C и A.
- Raft реализует CP: при partition система жертвует доступностью части узлов (в меньшей части, без кворума, записи недоступны), но сохраняет консистентность и избегает конфликтов.
- Если система предпочитает A при partition (AP), она даст ответы на запросы в каждой части, но состояние может расходиться (и потребуются механизмы слияния/разрешения конфликтов).
Проектирование транзакций и согласованных операций
Варианты проектирования транзакционных операций на кластере с Raft:
1) Универсальный ордер через единый Raft (централизованное упорядочивание)
- Все транзакции проходят через один Raft‑кластер (или через согласованный лидерный сервис): каждая транзакция — команда в распределённом логе; применяются последовательно => простая линейная консистентность.
- Плюс: простота, сильная согласованность. Минус: узкое место — пропускная способность и большая латентность при геораспределённой сети.
2) Пер‑шарда Raft + распределённый коммит (2PC поверх консенсуса)
- Каждая шардa управляется своим Raft‑кластером. Транзакция затрагивает несколько шард — нужен протокол атомарного коммита.
- Один подход: координатор (реплицирован через Raft для отказоустойчивости) выполняет two‑phase commit:
- Prepare: координатор посылает участникам запрос подготовить — участники помещают "prepare" запись в свой Raft‑лог и отвечают. Подготовка закрепляется только после достижения их локального кворума.
- Commit: если все участники подготовились, координатор записывает "commit" в свой Raft‑лог и рассылает команду commit; участники применяют изменение при видимости commit.
- Это даёт атомарность и согласованность, но добавляет два раунда сообщений и сложнее при partition — если координатор не имеет кворума он не сможет продвинуть решение.
3) Paxos/Raft‑Commit (консенсус для решения коммита)
- Вместо классического 2PC можно использовать распределённый commit, где решение о commit принимается через согласованный сервис (например, каждое решение тоже идёт через Raft/Paxos) — устраняет одиночный точечный сбой координатора, но схож по затратам.
4) Детеминированное упорядочивание (Calvin/Pipelined)
- Сервис упорядочивания предварительно даёт глобальную последовательность транзакций; исполнители (реплики) применяют их детерминированно. Уменьшает блокировки, но требует сложной предварительной маршрутизации и может ухудшать задержки.
Чтения и линейная консистентность
- Линейные запросы: читать только у лидера или использовать ReadIndex (Raft) — лидер обеспечивает, что ответ отражает все ранее подтверждённые операции.
- Более доступные, но слабее — читаются со слейвов (может быть устаревшее состояние).
Формулы и требования по кворуму / устойчивости
- Кворум большинства в Raft/Paxos: $q=\lceil \frac{N}{2}\rceil$. Система переживёт до $N-q$ одновременных падений.
- PBFT требует $N\ge 3f+1$ для устойчивости к $f$ византийским узлам; кворум для ответа обычно $2f+1$.
Практические замечания и компромиссы
- При геораспределении выбирать баланс: локальные лидеры для ноды в дата‑центрах + маршрутизация записей через ближайший лидер или через глобальный лидер.
- Латентность транзакций растёт с расстоянием между репликами, так как подтверждение требует кворума.
- Для высокого throughput — шардирование + параллельная обработка на разных шардах, но тогда сложнее обеспечить кросс‑шард транзакции.
- Для критичных по согласованности систем выбирайте CP (Raft/Paxos); если важнее доступность в partition — проектируйте схему разрешения конфликтов (CRDT, векторные часы) и допускайте eventual consistency.
Короткая сводка
- Сценарий: кластеры реплик по шардам, partition между дата‑центрами.
- Протокол: Raft (CP) для сохранения линейной согласованности; PBFT при византийских угрозах.
- Транзакции: два подхода — глобальное упорядочивание через единый Raft (простая согласованность) или per‑shard Raft + 2PC / Raft‑commit для кросшардовых транзакций; каждый выбор даёт trade‑off между производительностью, простотой и доступностью при partition.