Кратко: «транзакционная целостность при параллельной записи» достигается координацией (согласованием порядка и атомарностью коммитов) или отказом от строгой глобальной атомарности в пользу локальной + согласования конфликтов. Ниже — техники, их суть и компромиссы, затем сравнение в терминах CAP.
1) Основные свойства, которые нужно сохранить
- атомарность, согласованность, изоляция, долговечность (ACID) — если требуете строгих ACID глобально, нужны протоколы координации/консенсуса;
- при слабых требованиях — можно использовать модели типа eventual/causal/ snapshot.
2) Протоколы атомарного коммита между участниками
- Two‑Phase Commit (2PC): координатор собирает готовность у участников, затем посылает commit/abort. Плюсы: прост; минусы: блокируется при падении координатора, требует лока/резервирования ресурсов.
- Three‑Phase Commit (3PC): уменьшает вероятность блокировки, но не решает полностью сетевые разделения.
3) Консенсусные протоколы (RAFT / Paxos)
- Репликация и согласование через консенсус дают линейнуюizability/сильную согласованность. Часто применяют per‑shard consensus (каждый шард — группа реплик на RAFT). Плюсы: отказоустойчивость, строгая согласованность; минусы: высокая задержка (несколько RTT), при разделении — жертвуете доступностью, сложность реализации.
- Для кросс‑шард транзакций можно либо использовать глобальный координатор + 2PC поверх shard‑consensus, либо дизайн с глобальным консенсусом (дорого).
4) Кворумы (Quorum reads/writes)
- Модель: $N$ реплик, записей пишут в $W$ реплик, читают из $R$. Гарантия последней записи если $$R+W>N.$$
- Плюсы: простая масштабируемость; минусы: можно получить «псевдо‑согласованность», сложность при динамике реплик.
5) MVCC и временные штампы
- Multi‑Version Concurrency Control + глобальные/логические временные метки (timestamp ordering, snapshot isolation). Позволяет параллельные чтения и запись старых версий; для глобальной серийности нужен механизм глобального порядка (например, Spanner использует TrueTime).
- Плюсы: меньшая блокировка; минусы: нужна глобальная синхронизация времени или дополнительная координация для строгой сериализуемости.
6) Оптимистическая проверка конфликтов / SSI
- Выполняют транзакции локально, проверяют при коммите (оптимистично). Serializability via SSI (serializable snapshot isolation). Плюсы: лучше для высококонкурентных нагрузок; минусы: возможные откаты при конфликтах.
7) Детеминированные исполнители / предварительная ордеринга (Calvin, deterministic DBs)
- Сначала глобально упорядочивают операции (sequencer), затем исполняют детерминированно на шард‑узлах без синхронизации во время выполнения. Плюсы: отсутствие 2PC во время выполнения, плоская масштабируемость; минусы: необходимость централизованной очереди/шедулера, увеличение задержки на фазе ордеринга.
8) CRDT и eventual consistency
- Конфликт‑свободные реплики (CRDT) обеспечивают сходимость без координации — хороши для счетчиков, наборов и т.п. Плюсы: высокая доступность и масштабируемость; минусы: не подходят для трансакций, требующих глобальных инвариантов (балансы, перекиды средств).
9) Дизайн для уменьшения кросс‑шард конфликтов
- Шардировать данные так, чтобы транзакции были локальными; использовать colocated data; применять idempotency, retries, Sagas (компенсирующие действия) для долгих/распределённых бизнес‑операций.
Сравнение CAP и картирование подходов
- CAP: невозможно одновременно обеспечить Consistency, Availability и Partition tolerance. В реальных распределённых системах partition tolerance ($P$) обязателен, поэтому приходится выбирать между Consistency ($C$) и Availability ($A$).
- CP (Consistency + Partition tolerance, жертва Availability): системы на консенсусе (Paxos/RAFT, Spanner) — при partition часть узлов теряет доступность, но данные остаются согласованными (strong consistency/linearizability/serializability). Подходит, когда неверное/несогласованное состояние недопустимо (банковские транзакции).
- AP (Availability + Partition tolerance, жертва Consistency): системы eventual/causal/CRDT, асинхронная репликация, некоторые quorum-конфигурации с малой $W$ — остаются доступными при разделении, но данные могут временно расходиться и требовать слияния/разрешения конфликтов. Подходит для высокой доступности и толерантности к противоречиям (когортный чат, кэш).
Практические рекомендации
- Если нужны строгие глобальные транзакции и корректность важнее доступности: используйте per‑shard consensus (RAFT/Paxos), глобальный координационный протокол или Spanner‑подобные временные метки; ожидайте задержек и снизьте кросс‑шард транзакции.
- Если важна доступность и масштаб: минимизируйте глобальную координацию, применяйте кворумы, CRDT или Sagas с компенсирующими транзакциями и явной логикой разрешения конфликтов.
- Средний путь: оставить сильную согласованность в пределах небольших шардов (CP локально) и AP для межшардовых операций; либо использовать детерминированный ордеринг, чтобы убрать синхронизацию во время исполнения.
Короткое резюме:
- Для полной транзакционной целостности при параллельных записях нужен механизм координации/консенсуса (стоимость: задержка, возможная потеря доступности в разрывах).
- Если жёсткая целостность не требуется, можно получить высокую доступность и масштаб за счёт асинхронной репликации, CRDT или компенсаций, но придётся решать конфликты на уровне данных/приложения.