Кратко — виды подходов, их свойства и где применять.
1) ACID vs BASE
- Суть:
- ACID — строгие транзакции: атомарность, согласованность, изолированность, устойчивость. Подразумевает синхронную координацию для гарантии корректности.
- BASE — «в основном доступно, мягко согласовано, конечная согласованность» (eventual consistency). Смещает акцент на доступность и масштабируемость, допускает временные расхождения.
- Когда выбирать:
- ACID — финансы, инвентаризация, бронирования, критичная бизнес-логика, где коррекция ошибок дороже задержек.
- BASE — социальные фиды, аналитика, кэширование, высоконагруженные пользовательские сервисы, где важна доступность/латентность.
- Компромиссы: по CAP при разделении сети нельзя иметь одновременно сильную согласованность и доступность; ACID жертвует доступностью/латентностью ради согласованности, BASE — наоборот.
2) Двухфазный коммит (двухфазный протокол, $2$-фазный коммит, $2PC$)
- Суть: централизованный координатор собирает «готовность» от всех участков, затем отправляет commit/abort. Имеет фазы: prepare и commit.
- Свойства: обеспечивает атомарный коммит между ресурсами при наличии надёжной координации; не решает проблемы отказа (блокируемый — при падении координатора участники могут ждать).
- Когда применять: распределённые транзакции между согласованными сторожами (shards) в системах с относительным контролем над инфраструктурой; полезен когда нужна атомарность по множеству локальных хранилищ и приемлема задержка/сложность.
- Ограничения: блокировка ресурсов при сбоях, накладные расходы на сетевые раунды; часто комбинируется с согласованными репликами (см. ниже) и с механизмами восстановления (координатор-резерв).
3) Paxos (семейство алгоритмов консенсуса)
- Суть: асинхронный отказоустойчивый консенсус для репликации состояния; гарантирует безопасность в условиях отказов до $f$ узлов при наличии большинства.
- Свойства: формально корректен и устойчив, но сложен в реализации; требует большинства $\lceil n/2\rceil$ реплик для прогресса.
- Где используют: системные сервисы для конфигурации/блокировок/метаданных (Google Chubby), распределённые координаторы транзакций, некоторые реализации LWT (compare-and-set).
- Когда применять: когда нужна строгая согласованность и устойчивость к отказам, и когда можно платить цену за репликацию и задержку; хорошо для небольшого количества ключевых метаданных и лидеров.
4) Raft
- Суть: современный алгоритм консенсуса, эквивалентный Paxos по свойствам, но проще для понимания и реализации; лидер-ориентирован.
- Свойства: тот же принцип большинства $\lceil n/2\rceil$ для прогресса; проще реализовать устойчивую репликацию, лог и фейловер.
- Где используют: etcd, Consul, CockroachDB (ранги), многие новые кластеры для метаданных и координаторов.
- Когда применять: когда нужна надёжная репликация и понятная реализация; хорош для распределённых ключ-значение хранилищ, конфигов, сервисов координации, и для реализации устойчивых реплик диапазонов/partition’ов в транзакционных БД.
5) Практические комбинации и шаблоны
- Consensus + 2PC: каждая шарда хранится через консенсусную группу (Paxos/Raft), а глобальный commit делается через $2PC$. Примеры: Spanner (Paxos + глобальный commit с TrueTime), CockroachDB (Raft per range + распределённые транзакции). Это даёт сильную консистентность с отказоустойчивостью, но высокую задержку и сложность.
- Leaderless / quorum-подходы (BASE-style): Cassandra, Dynamo — чтения/записи с настраиваемой консистентностью (quorum reads/writes), высокая доступность и масштаб. Для отдельных операций, требующих CAS/linearizability, используется Paxos/LWT.
- Sagas / компенсирующие транзакции: для микросервисов, где $2PC$ неприемлем из‑за связности — разбивают монолитную транзакцию на последовательность локальных транзакций с компенсаторами (подходит для eventual consistency).
6) Практические рекомендации (когда что предпочесть)
- Нужна строгая согласованность и атомарность между шардами → использовать консенсусные группы + распределённый commit ($2PC$ поверх Paxos/Raft). Подходит для банковских систем, систем биллинга; пример: Spanner, CockroachDB.
- Нужна высокая доступность и масштаб, согласованность не критична мгновенно → BASE/leaderless/quorum (Cassandra, Dynamo), либо Sagas для бизнес-процессов в микросервисах.
- Нужны координация, конфигурация, метаданные, лидеры → использовать Raft/Paxos (etcd/Consul/ZooKeeper/Chubby).
- Простота реализации и поддерживаемость → Raft чаще предпочтителен (ясный лог лидерства, реализации).
- Геораспространённые системы с требованиями глобальной внешней согласованности → специальные механизмы (TrueTime/синхронные мин/макс временные окна) + consensus + глобальный commit; высокая стоимость — применять только при необходимости.
Коротко о стоимости:
- Сильная согласованность = больше сетевых раундов, задержек, сложность восстановления.
- BASE/кворумы = лучшее масштабирование и доступность, но сложнее писать корректную бизнес-логику (уметь терпеть асинхронность).
Если нужно — могу дать сводную таблицу «подход — преимущества — недостатки — примеры систем» для быстрого выбора.