Кратко и по делу.
1) Выбор по теореме CAP
- Для банковских переводов приоритет — согласованность + устойчивость к разбиениям сети (CP). Это означает: при сетевом разделении система может временно снижать доступность записей/записей на запись, но не допускать расхождений балансов.
- Формула кворумов: при N репликах достаточно обеспечить кворумы чтения $R$ и записи $W$ так, чтобы
$$R+W>N$$
обычно $W=\lfloor N/2\rfloor +1$ (большинство) для сильной согласованности.
2) Общая архитектура компонентов
- Хранилище по шартам (shards) — каждый шард — кластер с консенсусом (Raft/Paxos) для обеспечения линейной согласованности локально.
- Транзакционный координатор (может быть распределённый и реплицирован) — ведёт глобальные трансакции; его состояние хранится в устойчивом журнале (consensus-backed).
- Таблица дедупликации транзакций: запись состояния каждой логической операции по ключу $TxID$.
- Журнал (WAL) на каждом участнике для prepare/commit/abort.
3) Протокол гарантии «именно один раз» и атомарности (рекомендуемая схема)
Используем 2PC с консенсусным хранением состояния координатора (получаем CP-поведенье и надёжность при падениях).
Сценарий перевода со счёта A (шард $S_A$) на B (шард $S_B$), транзакция $TxID$:
Шаги:
1. Клиент -> координатор: запрос перевода с уникальным $TxID$. Координатор проверяет в таблице дедупликации — если уже выполнено/в процессе, возвращает статус (идемпотентность).
2. Координатор инициирует prepare: посылает Prepare($TxID$, debit A, credit B) участникам $S_A$, $S_B$.
3. Каждый участник выполняет локальную проверку и резервирование:
- Проверяет, что $TxID$ ещё не обработан; пишет в WAL запись "prepared $TxID$" и резервирует сумму (логически уменьшает доступный баланс или ставит блокировку).
- Возвращает VoteCommit / VoteAbort.
4. Если координатор собрал большинство/все голосов Commit, он записывает durable запись "commit $TxID$" (в consensus-хранилище) и рассылает Commit. Участники применяют изменения из prepare и удаляют резерв. Если хоть один проголосовал Abort — координатор пишет "abort $TxID$" и рассылает Abort; участники откатывают резерв.
5. После Commit координатор отмечает $TxID$ как завершённый в таблице дедупликации; ответ клиенту.
Ключевые детали для exactly-once:
- Все сообщения идемпотентны по $TxID$ — повторный Prepare/Commit/Abort обрабатывается безопасно.
- Координатор и участники хранят состояние транзакции в устойчивом хранилище, чтобы восстановиться после падения.
- Доставка сообщений — как минимум once; дедупликация обеспечивает exactly-once семантику.
4) Обработка отказов сети и откаты
- Координатор упал: другой реплицированный координатор читает состояние транзакции из consensus-backed журнала и продолжает (решение устойчиво).
- Участник упал после Prepare, перед Commit: при восстановлении читает WAL, видит prepared; связывается с координатором (или через реплику координатора) чтобы узнать финальное решение; если координатор недоступен — участник ждёт или, при политике таймаута и при отсутствии решения, запускает процедуру восстановления через консенсус (в крайнем случае — координатор на стороне участников инициирует abort по политике).
- Сетевой разрыв между шардами: из-за CP-приоритета система может блокировать новые записи (снижение доступности) пока не восстановится достаточный кворум для гарантии консистентности. Это предотвращает двойную трату.
- Таймауты и компенсации: если бизнес может допускать более сложные сценарии, можно использовать SAGA/компенсации для длинных процессов, но это дает только eventual consistency и требует аккуратной договорённости (не рекомендуено для базовых денежных переводов).
5) Дополнительные меры предотвращения двойной записи / двойной траты
- Локальные блокировки/резервация средств при Prepare.
- Atomic ledger entries: каждое изменение — неизменяемая запись в журнале с ссылкой на $TxID$.
- Проверки баланса и дублирования на уровне WAL/ledger.
- Использование MVCC / линейной консистенции на уровне аккаунта (каждое чтение/запись должно попадать на лидер реплики).
6) Практические рекомендации
- Реализуйте все критичные долговременные состояния (статусы транзакций) в согласованном реплицированном сторе (Raft cluster).
- Минимизируйте размер глобальных 2PC-транзакций (чтобы меньше блокировок).
- Метрики и автоматический recovery (watchdog), детектирование «подвисших» prepared и безопасный механизм принудительного Abort/administrative recovery.
- Тестирование сетевых разделений и восстановлений (chaos testing).
- Аудитные логи и мониторинг для финансовой проверяемости.
Итого: выбираем CP (сильная согласованность, потеря доступности при разбиении); реализуем кворумное реплицирование (Raft/Paxos), 2PC поверх консенсусного хранилища + идемпотентность по $TxID$, устойчивый WAL и таблицу дедупликации — это обеспечивает атомарность, откаты и семантику «именно один раз» при сетевых сбоях.