Проблема – состояние гонки (race condition):
Два процесса одновременно читают
value = 5, увеличивают в памяти до 6, затем оба записывают 6. В результате значение станет 6, хотя должно было стать 7 (потерян один инкремент).Решение – атомарный UPDATE:
В большинстве реляционных СУБД (PostgreSQL, MySQL, Oracle) оператор
UPDATE SET value = value + 1 является атомарным. База данных блокирует строку на время обновления, но не блокирует чтение (за счёт MVCC в PostgreSQL или разных механизмов). При параллельных вызовах второй вызов увидит уже увеличенное значение и корректно увеличит его ещё раз.Почему не подходят другие варианты:
A (два отдельных запроса) – не атомарно, гонка неизбежна.
C (
SELECT ... FOR UPDATE) – да, решает проблему, но блокирует строку даже для чтения другими транзакциями (пессимистическая блокировка). Это может снизить производительность. Атомарный UPDATE обычно быстрее.D (UPSERT) – работает, но тяжеловесно, если гарантированно существует запись.
Важно для аналитика:
Если нужен атомарный инкремент – используйте один UPDATE.
Если нужно прочитать старое значение перед обновлением (например, для логирования), то придётся использовать
SELECT ... FOR UPDATE в транзакции.Для высоконагруженных счётчиков (лайки, просмотры) часто используют Redis (атомарный
INCR), а периодически синхронизируют с БД.Реальный пример:
В счетчике просмотров видео на YouTube используется атомарный UPDATE в базе данных для финальной консистентности, а промежуточные инкременты накапливаются в Redis.
Что должен зафиксировать аналитик:
«При обновлении счётчика использовать атомарный
UPDATE SET field = field + 1 без предварительного чтения».Если нужно получить предыдущее значение – оформить требование на пессимистическую блокировку.
Вывод: Простой атомарный UPDATE – самое производительное и надёжное решение для счётчиков без необходимости читать старое значение.