Laravel: транзакції й конкурентність
20 питань · ~20 хв · Версія v3.0
Увійдіть, щоб продовжити
Транзакції й неявні коміти, дії після коміту для завдань, подій і листів, блокування рядків, гонки й ідемпотентність - питання всіх рівнів, від junior до lead.
- За спробу
- 20
- У пулі
- 52
- Проходжень
- 0
- Середній бал
- -
- Пройшли на 70%+
- -
Питання для підготовки
21 питанняIdempotency (ідемпотентність) - багаторазове виконання операції дає той самий результат, що й однократне. Критично для платежів і повторів завдань у чергах (де доставка «at least once»).
Реалізація для API - idempotency key:
$key = $request->header('Idempotency-Key');
return Cache::lock("idem:$key")->block(5, function () use ($key) {
if ($cached = Cache::get("idem:result:$key")) {
return $cached; // повернути попередній результат
}
$result = $this->charge(); // виконати один раз
Cache::put("idem:result:$key", $result, now()->addDay());
return $result;
});
Для завдань: перевірка «вже оброблено» за унікальним ключем, ShouldBeUnique, або БД-обмеження, що відсікають дублі.
Pessimistic locking блокує рядок у БД до завершення транзакції - інші транзакції чекають.
DB::transaction(function () {
$account = Account::lockForUpdate()->find($id); // блокування на запис
$account->balance -= 100;
$account->save();
});
sharedLock() - блокування на читання.
Optimistic locking не блокує, а перевіряє версію/updated_at перед записом; якщо хтось уже змінив рядок - оновлення відхиляється, операцію повторюють.
UPDATE accounts SET balance = ?, version = version + 1
WHERE id = ? AND version = ?
- Pessimistic - для високої конкуренції за тими ж рядками (платежі, склад).
- Optimistic - коли конфлікти рідкісні; масштабується краще, бо не тримає блокувань.
Транзакція гарантує атомарність: або всі операції виконуються, або жодна.
DB::transaction(function () use ($order) {
$order->save();
$order->items()->createMany($items);
Inventory::decrement($order->product_id, $order->qty);
});
При винятку всередині замикання Laravel автоматично робить rollBack(). Ручний контроль:
DB::beginTransaction();
try {
// ...
DB::commit();
} catch (Throwable $e) {
DB::rollBack();
throw $e;
}
Другий аргумент transaction($cb, 3) задає кількість повторів при deadlock.
Deadlock - дві транзакції взаємно блокують одна одну, чекаючи на ресурси, які тримає інша. СУБД виявляє це й «вбиває» одну з транзакцій.
Запобігання:
- Єдиний порядок доступу до таблиць/рядків у всіх транзакціях.
- Тримати транзакції короткими, блокувати якомога пізніше.
- Правильні рівні ізоляції (не завищувати без потреби).
Обробка в Laravel - автоматичний повтор:
DB::transaction(function () {
// ...
}, attempts: 3); // повторити при deadlock
Діагностика: SHOW ENGINE INNODB STATUS (MySQL), логи БД, моніторинг частоти deadlock. Інколи допомагає optimistic locking замість тривалих блокувань.
Це «upsert»-методи, що позбавляють від ручних перевірок «існує / не існує».
// знайти за email; якщо нема - створити з усіма атрибутами
User::firstOrCreate(
['email' => $email],
['name' => $name]
);
// знайти за email; оновити name; якщо нема - створити
User::updateOrCreate(
['email' => $email],
['name' => $name]
);
Перший масив - умови пошуку, другий - значення для створення/оновлення. Споріднений firstOrNew() повертає незбережений екземпляр.
Прочитати - ще не значить знати
20 питань, по одному на екран, ~20 хв. Після завершення - розбір кожної помилки з посиланням на питання.