Кратко — сначала принципиальные различия, потом когда что нужно, затем практические приёмы для геораспределённых систем.
1) Централизованные ACID-транзакции (классическая реляционная модель)
- Свойства: Atomicity, Consistency, Isolation, Durability — «строгая» семантика, часто гарантирующая сериализуемость или внешнюю согласованность.
- Когда нужны: финансовые операции, учёт балансов, инвентаризация, критичные бизнес-процессы, где некорректное состояние недопустимо.
- Механизмы: блокировки, MVCC, $2$-фазная фиксация (2PC) для распределённых коммитов; плюсы — предсказуемая корректность, минусы — задержки и снижение пропускной способности при масштабировании.
2) Распределённые и NoSQL-модели — BASE и компромиссы
- BASE: Basically Available, Soft state, Eventual consistency — система предпочитает доступность и масштабируемость, допуская временные расхождения.
- Типы слабой согласованности: eventual, causal, read-your-writes, session consistency, tunable consistency.
- Обычные компромиссы: отказ от глобальной сериализуемости, асинхронная репликация, разрешение конфликтов по политике (LWW — last write wins), или на уровне приложения.
- Пример техники: настройка кворумов в системах вроде Cassandra: требование $R+W>N$ (где $N$ — число реплик, $R$ — чтений, $W$ — записей) обеспечивает кворумную согласованность.
- Когда достаточно BASE: ленты соцсетей, логирование, аналитика, кеши, где кратковременные расхождения допустимы.
3) Проблемы геораспределённости и способы обеспечения согласованности
- Ограничение: сеть даёт задержки; при требовании глобальной синхронной согласованности задержка как минимум равна междатценровому RTT: $\text{latency}\gtrsim \text{RTT}$. Это фундаментальный компромисс производительности.
- Строгая согласованность (линеаризуемость/внешняя): реализуется через распределённый консенсус (Paxos, Raft) или глобальные часы (Google Spanner + TrueTime). Минус — высокая задержка при межрегиональных операциях.
- Пример: Spanner использует глобальную синхронизацию времени с неопределённостью $ϵ$ и делает «commit-wait» для внешней согласованности.
- Альтернативы/гибриды:
- Локальная сильная согласованность + геораспределённая асинхронная репликация (шардирование по региону).
- Кворумы/тюнинг согласованности: выбирать $R,W,N$ в зависимости от требований доступности/латентности.
- Causal consistency и session guarantees: слабее линеаризуемости, но удобнее для UX (read-your-writes) и дешевле по латентности.
- CRDT (конфликтно-устойчивые структуры данных) для автоматического слияния и гарантии сходимости без глобального координатора.
- Конфликтно-ориентированные протоколы и трансформации (OT/CRDT) для редактирования данных офлайн.
- Разрешение конфликтов: LWW, application-specific merge, compensating transactions; anti-entropy (мердж-фоновые процессы), read-repair.
4) Практические рекомендации
- Если нужен строгий консистентный результат сразу (финансы, права, критичные инварианты) — использовать транзакции на согласованном уровне (консенсус/синхронная репликация) и быть готовым к межрегиональной латентности.
- Если важна доступность и масштаб — проектировать для eventual/causal consistency, применять CRDT или кворумы, делегировать разрешение конфликтов приложению.
- Гибрид: держать критичные данные в глобально согласованных сервисах, менее критичные — в региональных/асинхронных хранилищах.
- Тестировать и формализовать инварианты: чётко документировать, какие аномалии допустимы (lost update, write skew, stale read), и подбирать модель согласованности под них.
Коротко: ACID = строгая корректность за счёт задержек и лимитируемой масштабируемости; BASE/NoSQL = высокая доступность и масштаб за счёт временной несогласованности и сложной логики слияния. В геораспределённых системах выбор между производительностью и строгой согласованностью реализуют через консенсусные протоколы, кворумы, CRDT и гибридные архитектуры.