Увійти Реєстрація
Блог Серії
Кар'єра
Вакансії Компанії
Навчання
Документація Співбесіди Тестування Відео
Екосистема
Пакети Ресурси Проєкти Інструменти Події
Інше
Про нас Реклама

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() повертає незбережений екземпляр.

Докладніше в документації: Eloquent: upsert-методи

Прочитати - ще не значить знати

20 питань, по одному на екран, ~20 хв. Після завершення - розбір кожної помилки з посиланням на питання.