Транзакции в Laravel: архитектурные последствия

Типичная авария на боевом проекте: пользователь оформил заказ, платёжный шлюз списал деньги, а через пять минут в базе заказа нет. В логах — Deadlock found when trying to get lock и откат транзакции. Письмо «спасибо за покупку» при этом ушло. Причина не в платёжке и не в MySQL, а в том, как код на Laravel обращается с DB::transaction(): разработчик считал вызов метода атомарной операцией, а получил вложенные транзакции, события внутри блокировки и очередь, которая читает ещё не закоммиченную запись.

Разберём, что именно происходит внутри DB::transaction в Laravel 11.x, где границы транзакции влияют на архитектуру, а не только на пару строк кода, и какие решения приходится закладывать заранее, чтобы не переписывать сервисный слой после первого дедлока в проде.

Что делает DB::transaction на самом деле

Замыкание, переданное в DB::transaction(), выполняется между BEGIN и COMMIT. Если внутри вылетает исключение — вызывается ROLLBACK и исключение пробрасывается наружу. Второй аргумент — число повторов при дедлоке: Laravel ловит коды ошибок дедлока и сериализации и повторяет замыкание целиком. Это первый архитектурный подвох: всё содержимое замыкания может выполниться несколько раз.

Если внутри транзакции вы отправляете HTTP-запрос в платёжный шлюз или пишете в Redis, повтор при дедлоке отправит запрос дважды. Внешние побочные эффекты внутри блока с ретраями — почти всегда ошибка проектирования.

Транзакция защищает согласованность строк в одной базе. Она не защищает письма, HTTP-вызовы, файлы и записи в другую СУБД. Всё, что не откатывается вместе с ROLLBACK, нужно выносить за границу транзакции сознательно.

Вложенные транзакции — это не транзакции

Когда DB::transaction() вызывается внутри уже открытой транзакции, Laravel не открывает вторую — драйвер PDO этого не умеет. Вместо этого создаётся точка сохранения (SAVEPOINT). Внутренний «откат» откатывает только до savepoint, а реальный COMMIT происходит на самом внешнем уровне.

Последствие: если сервисный метод createOrder() оборачивает всё в транзакцию и вызывается из другого метода, который тоже открыл транзакцию, ваш «атомарный» блок на деле лишь часть чужой транзакции. Уровень вложенности виден через DB::transactionLevel() — если он больше единицы, вы внутри чужой границы.

Где транзакция ломает предположения о порядке событий

Самая частая и дорогая проблема — события и очереди внутри транзакции. Классический сценарий:

// Laravel 11.x
DB::transaction(function () use ($cart) {
    $order = Order::create([
        'user_id' => $cart->user_id,
        'total'   => $cart->total,
    ]);

    foreach ($cart->items as $item) {
        $order->items()->create($item->toArray());
    }

    // Задача уходит в очередь ПРЯМО СЕЙЧАС,
    // до COMMIT внешней транзакции
    SendOrderConfirmation::dispatch($order);
});

Если очередь работает на драйвере redis или sqs, задача попадёт в брокер до коммита. Воркер может подхватить её за миллисекунды и обратиться к базе за Order, которого там ещё нет — транзакция не завершилась. Итог — ModelNotFoundException в воркере на, казалось бы, только что созданной записи.

Решение: afterCommit

Laravel умеет откладывать диспетчеризацию до коммита. Способа два:

• глобально — параметр after_commit в конфиге соответствующего соединения очереди (config/queue.php), проверьте наличие ключа в актуальной версии;
• точечно — метод afterCommit() на объекте задачи или свойство public bool $afterCommit = true; в классе задачи и в mailable.

// Диспетчеризация произойдёт только после COMMIT
SendOrderConfirmation::dispatch($order)->afterCommit();

Тот же механизм работает для событий модели через $afterCommit в слушателе. Но здесь кроется ловушка: afterCommit срабатывает на коммите самой внешней транзакции. Если код исполняется вне транзакции вообще, задача уйдёт немедленно — что как раз и нужно.

Границы транзакции как архитектурное решение

Вопрос «что положить внутрь транзакции» — не про удобство, а про то, где проходит граница согласованности. Три подхода, которые встречаются в реальных проектах:

Для монолита на одной базе рабочий выбор — узкая транзакция в сервисе, охватывающая только запись связанных строк. Всё, что обращается наружу, уходит через afterCommit или ставится в очередь после выхода из блока.

Блокировки и время удержания

Пока транзакция открыта, строки под SELECT ... FOR UPDATE (в Eloquent — lockForUpdate()) заблокированы. Чем дольше живёт транзакция, тем выше шанс, что другой запрос упрётся в блокировку или словит дедлок. HTTP-вызов на 400 мс внутри транзакции — это 400 мс, на которые строка недоступна конкурентам.

Правило простое: внутри транзакции только работа с базой. Никаких Http::get(), sleep(), чтения больших файлов и обращений к сторонним API.

Что ломается первым под нагрузкой

При росте параллельности проявляются проблемы, невидимые на одном запросе:

• Дедлоки на порядке блокировок. Два запроса блокируют строки A и B в разном порядке. MySQL выбирает жертву и откатывает её транзакцию. Если у вас настроены ретраи — замыкание выполнится заново со всеми побочными эффектами внутри.
• Lock wait timeout. Запрос ждёт освобождения блокировки дольше innodb_lock_wait_timeout и падает. Обычно признак того, что внутри транзакции есть что-то медленное.
• Разбухание пула соединений. Долгие транзакции держат соединение занятым. При лимите соединений в базе воркеры и веб-процессы начинают конкурировать за пул.
• Двойные внешние эффекты. Ретрай дедлока повторяет весь блок — включая тот Http::post(), который забыли вынести.

Как это мерить

Не гадайте — смотрите на цифры:

• в MySQL — SHOW ENGINE INNODB STATUS, раздел LATEST DETECTED DEADLOCK, и счётчик Innodb_deadlocks через SHOW GLOBAL STATUS;
• в приложении — время удержания транзакции: залогируйте microtime до DB::transaction и после, вынесите в метрику;
• в очереди — процент задач, падающих с ModelNotFoundException: прямой индикатор диспетчеризации до коммита.

Идемпотентность вместо надежды на атомарность

Как только процесс выходит за пределы одной базы — появляется платёж, вызов стороннего API, запись в другую СУБД — транзакция перестаёт быть достаточной гарантией. Здесь работает не «сделать всё атомарно», а «сделать каждый шаг повторяемым безопасно».

Практический приём — уникальный ключ идемпотентности на операцию. Перед списанием денег создаёте запись с уникальным idempotency_key в транзакции. Повторный вызов с тем же ключом упрётся в нарушение уникального индекса и не спишет дважды. Это дешевле и надёжнее, чем пытаться растянуть транзакцию на внешний сервис.

Что делать дальше

Пройдитесь по сервисному слою с тремя вопросами к каждому блоку DB::transaction: нет ли внутри внешних вызовов; помечены ли задачи и события как afterCommit; сколько строк и как долго блокируется. Настройте логирование времени транзакций и алерт на рост Innodb_deadlocks. Для операций, выходящих за пределы одной базы, заложите ключ идемпотентности до того, как проект встретит первый повторный платёж. Границы транзакции проще проектировать заранее, чем расшивать после инцидента.