Коротко: при вашей схеме (Users(id, name, balance) + Transactions(id, user_id, amount)) типичная причина «потерянных обновлений» — чтение баланса, вычисление нового значения в приложении и запись его обратно без блокировок или проверки версии. Ниже — анализ аномалий, конкретные транзакционные схемы и архитектурные альтернативы с обсуждением компромиссов.
1) Какие аномалии возможны и как они проявятся
- Lost update — два клиента читают одно и то же balance, каждый вычисляет new = old ± x и пишут; одно обновление «перепишет» другое. Частая причина.
- Dirty read — транзакция читает несохранённый (uncommitted) баланс другой транзакции. Решается обычными уровнями изоляции; редко причина потери обновлений, но может давать неверные расчёты.
- Phantom — если баланс вычисляется как агрегат по таблице Transactions (например, `SUM(amount)`), параллельная вставка/удаление транзакций может изменить агрегат между двумя чтениями. Для предотвращения нужен сериализуемый вид или работа с материальной колонкой balance.
2) Быстрые практические fixes (низкая сложность, хорошая производительность)
- Использовать атомарное обновление в БД:
SQL-паттерн (в рамках одной транзакции):
INSERT INTO Transactions(id, user_id, amount) VALUES(...);
UPDATE Users SET balance = balance + :amount WHERE id = :user_id;
— это устраняет lost update, если оба запроса выполняются в одной транзакции и UPDATE изменяет значение относительно текущего баланса (а не на основе ранее прочитанного в приложении).
Преимущество: очень дешёво, масштабируется; блокирует только строку при UPDATE.
- Гарантировать уникальность транзакций (idempotency): unique constraint на Transactions.id. При повторном retry приложение может повторно попытаться вставить транзакцию и корректно обработать уникальный ключ.
3) Пессимистическая блокировка (простая, стабильная при высоком конфликте)
- Схема (Postgres-подобная):
BEGIN;
SELECT balance FROM Users WHERE id = :id FOR UPDATE;
INSERT INTO Transactions(...);
UPDATE Users SET balance = balance + :amount WHERE id = :id;
COMMIT;
- Предотвращает lost updates: строка пользователя заблокирована пока транзакция не завершится.
- Компромисс: при высокой конкуренции — блоки/очереди, длительные транзакции снижают пропускную способность.
4) Оптимистическая блокировка (версия / CAS) — хороша при низкой частоте конфликтов
- Добавить колонку Users.version (integer).
- Читаете: SELECT balance, version FROM Users WHERE id = :id;
вычисляете new_balance = balance + amount;
BEGIN;
UPDATE Users
SET balance = :new_balance, version = version + 1
WHERE id = :id AND version = :old_version;
IF rows_affected = 0 THEN
rollback и retry (конфликт) — повторить чтение/применение;
ELSE
INSERT INTO Transactions(...);
COMMIT;
END IF;
- Преимущество: нет блокировок, хорошая скорость при редких конфликтах.
- Минус: при частых конфликтах — много повторных попыток и нагрузка на приложение.
5) Serializable / Snapshot Isolation — предотвращают феномены и фантомы
- Установить уровень транзакции SERIALIZABLE (или использовать SI/SSI в Postgres):
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
-- операция: прочитать, вставить транзакцию, обновить/проверить агрегат
COMMIT;
- БД гарантирует сериализуемое поведение, но при конфликте транзакция может быть отменена с ошибкой (SQLSTATE '40001') — нужно retry в приложении.
- Преимущество: простая корректность без ручных блокировок/versioning.
- Минус: увеличение числа откатов/retry и накладных расходов, меньше throughput при высоком параллелизме.
6) Если баланс вычисляется как агрегат Transactions (SUM) — нюансы фантомов
- Вариант а) материализованный баланс (storing balance) + атомические обновления (см. пункт 2).
- Вариант б) считать баланс как SUM(amount) и использовать SERIALIZABLE для предотвращения фантом-вставок, либо держать таблицу Transactions партиционированной и применять блокировки диапазона — обычно сложнее.
- Практически: хранение денормализованного баланса + транзакции-апдейты проще и эффективнее.
7) Архитектурные изменения (большая работа, высокая гибкость)
- Event Sourcing / Append-only events:
- Все операции — append-only в Events/Transactions (immutable).
- Баланс — вычисляемый агрегат (проекция), обновляемая асинхронно или в процессе записи с Optimistic Concurrency (version на агрегате).
- Плюсы: audit trail, гибкость, масштабируемость (шардирование событий).
- Минусы: сложность, eventual consistency, нужна стратегия реплея, snapshotting, idempotency.
- CQRS: командный путь записывает события (с версионной проверкой), читающие проекции обновляются асинхронно. Подходит для очень высокой нагрузки и сложной логики.
- Использование хранимых процедур/триггеров: выполнять вставку Transactions + изменение Users в одном атомарном блоке внутри БД (меньше сетевых RTT).
8) Рекомендованные конкретные варианты в зависимости от нагрузки/требований
- Низкая/умеренная нагрузка, нужно простое, быстрое решение:
- Atomic UPDATE (UPDATE SET balance = balance + :amount) + INSERT Transactions в одной транзакции; unique constraint на tx id; isolation level READ COMMITTED.
- Высокая конкуренция по одним и тем же счетам:
- Если конфликты часты — пессимистический SELECT ... FOR UPDATE (но следите за блокировками).
- Если конфликты редки — optimistic locking с version.
- Требуется строгая корректность агрегатов (например, вычисляете баланс через SUM) и нет желания менять модель:
- SERIALIZABLE / SSI + retry в приложении.
- Очень высокий масштаб, audit/переигрываемость важны:
- Event sourcing + CQRS, versioned aggregates, idempotency keys.
9) Практические дополнительные меры
- Всегда выполнять INSERT Transactions и UPDATE Users в одной транзакции (атомарность).
- Добавить уникальный idempotency key для каждой клиентской операции (unique constraint) — безопасный retry.
- Логировать и отслеживать количество retries/serialization failures, чтобы решить между optimistic vs pessimistic.
- Измерять: throughput, latency и процент abort/retry для выбранной схемы.
10) Короткое резюме компромиссов
- Atomic DB UPDATE + Transactions: быстрый, простой, решает lost updates; минимальные накладные расходы.
- FOR UPDATE (пессимистично): надежно при конкуренции, но снижает параллелизм (блокировки).
- Optimistic (version): лучше масштабируется при редких конфликтах, требует retry-логики.
- SERIALIZABLE: простая правильность, но больше abort'ов и затрат на согласование.
- Event sourcing/CQRS: масштабируемо и прозрачно, но сложность и eventual consistency.
Если нужно — могу привести готовые SQL-примеры для конкретной СУБД (Postgres / MySQL) для каждой схемы и шаблон retry-логики.