Как защитить баланс от двойного списания при гонке транзакций?

Как защитить баланс от двойного списания при гонке транзакций?

• Конкуренция транзакций, финансовые системы
• Организовать конкурентный контроль доступа к балансу
• Использовать атомарные операции либо транзакции с подходящим уровнем изоляции
• Доступны два подхода: оптимистичная проверка перед записью и пессимистичная блокировка
• На уровне БД применяют изоляцию Serializable или блокируют строку с балансом
• Для неблокирующей работы в памяти можно использовать CAS (Compare-And-Swap)
• Необходимо обеспечить целостность данных и отказоустойчивость
• На практике банки и платёжные системы используют транзакции на уровне БД либо сервисные мьютексы

Суть: чтобы исключить гонку, нельзя допускать одновременное изменение одной сущности. Для этого применяют блокировки или контроль версии и не позволяют списать средства дважды.

Подробный ответ

Основной ответ

Чтобы при параллельных запросах средства не списывались с баланса повторно, необходимо обеспечить консистентность данных и синхронизацию транзакций. Главная цель — исключить ситуацию, при которой несколько транзакций одновременно видят один и тот же доступный остаток и списывают сумму сверх него. Для решения задачи используют блокировки, механизмы оптимистичной и пессимистичной конкуренции, а также корректно настроенные транзакции базы данных.

Ключевые моменты

• Пессимистическая блокировка: в момент начала операции запись баланса учетной записи блокируется, поэтому остальные запросы на обновление ожидают освобождения записи. В реляционной БД такой подход реализуют через SELECT FOR UPDATE. Недостаток решения — рост задержек и уменьшение параллелизма при большом потоке запросов.
• Оптимистичная блокировка: вместе с балансом сохраняют версию или timestamp. Перед записью система проверяет, не изменилось ли это значение после чтения. При обнаружении изменений транзакция откатывается и выполняется повторно. Такой вариант сокращает время блокировок, однако требует правильно организовать повторную обработку.
• Атомарные операции и ACID-транзакции: проверку остатка и само списание следует выполнять внутри одной транзакции базы данных, чтобы сохранить гарантии изоляции. Например, PostgreSQL позволяет задать уровень изоляции SERIALIZABLE, предотвращающий фантомные чтения и другие аномалии.
• Идемпотентность и контроль состояния: в высоконагруженных системах полезно отслеживать операции, которые уже были обработаны, например с помощью уникальных идентификаторов транзакций. Это помогает предотвратить повторное списание при повторной отправке запроса.

Практический контекст

В высоконагруженных банковских сервисах обычно объединяют optimistic locking с повторными попытками с распределёнными менеджерами транзакций или SAGA-паттернами, обеспечивая надёжность операций. Redis и другие in-memory хранилища могут использоваться для блокировок, тогда как БД отвечает за точный контроль консистентности. Например, в PostgreSQL 14+ для критичных операций применяют advisory locks или explicit locking, снижая вероятность "гонок".