Розподілені транзакції · fullstack.org.ua

Просунутий23 хв· Fullstack Team

Розподілені транзакції

Порівняємо 2PC, 3PC та Saga й визначимо, як координувати зміни в кількох сервісах без спільної транзакційної бази.

Навіщо потрібні розподілені транзакції

У межах одного сервісу транзакція бази даних може гарантувати атомарність:

text

BEGIN
  списати кошти
  створити замовлення
COMMIT

Але в мікросервісній системі ці операції часто належать різним сервісам:

Order Service створює замовлення;
Payment Service списує кошти;
Inventory Service резервує товар;
Shipping Service створює доставку.

Кожен сервіс має власну базу даних і може бути незалежно розгорнутий. Спільної транзакції бази даних між ними немає.

text

Координатор              Сервіс A              Сервіс B
     |                       |                    |
     |------ PREPARE ------->|                    |
     |------ PREPARE ---------------------------->|
     |                       |                    |
     |<------- YES ----------|                    |
     |<-------------------------- YES ------------|
     |                       |                    |
     |------ COMMIT -------->|                    |
     |------ COMMIT ----------------------------->|
     |                       |                    |
     |<------- OK -----------|                    |
     |<-------------------------- OK -------------|

text

Координатор              Учасник A             Учасник B
     |                       |                    |
     |----- CanCommit? ----->|                    |
     |----- CanCommit? -------------------------->|
     |                       |                    |
     |<-------- YES ---------|                    |
     |<-------------------------- YES ------------|
     |                       |                    |
     |------ PRECOMMIT ----->|                    |
     |------ PRECOMMIT -------------------------->|
     |                       |                    |
     |<--------- ACK ---------|                    |
     |<-------------------------- ACK ------------|
     |                       |                    |
     |------- DOCOMMIT ------>|                    |
     |------- DOCOMMIT -------------------------->|

text

Оркестратор
    |
    |-- createOrder
    |-- reserveInventory
    |-- chargePayment
    |-- createShipment
    |
    |-- у разі помилки:
        |-- refundPayment
        |-- releaseInventory
        |-- cancelOrder

javascript

class InventoryService {
  constructor() {
    this.reservations = new Set();
  }

  async reserve(orderId) {
    // Локальна транзакція сервісу складу
    this.reservations.add(orderId);
    console.log(`Товар зарезервовано для ${orderId}`);
  }

  async release(orderId) {
    // Компенсувальна дія для резервування
    this.reservations.delete(orderId);
    console.log(`Резерв товару скасовано для ${orderId}`);
  }
}

class PaymentService {
  constructor() {
    this.charges = new Set();
  }

  async charge(orderId) {
    // Локальна транзакція сервісу платежів
    if (orderId === "order-fail-payment") {
      throw new Error("Платіж відхилено");
    }

    this.charges.add(orderId);
    console.log(`Платіж виконано для ${orderId}`);
  }

  async refund(orderId) {
    // Компенсувальна дія для платежу
    this.charges.delete(orderId);
    console.log(`Повернення коштів виконано для ${orderId}`);
  }
}

class OrderService {
  constructor() {
    this.orders = new Map();
  }

  async create(orderId) {
    // Локальна транзакція сервісу замовлень
    this.orders.set(orderId, "CONFIRMED");
    console.log(`Замовлення створено: ${orderId}`);
  }

  async cancel(orderId) {
    // Компенсувальна дія для створення замовлення
    this.orders.set(orderId, "CANCELLED");
    console.log(`Замовлення скасовано: ${orderId}`);
  }
}

class OrderSaga {
  constructor(orderService, inventoryService, paymentService) {
    this.orderService = orderService;
    this.inventoryService = inventoryService;
    this.paymentService = paymentService;
  }

  async execute(orderId) {
    const completedSteps = [];

    try {
      await this.orderService.create(orderId);
      completedSteps.push("order");

      await this.inventoryService.reserve(orderId);
      completedSteps.push("inventory");

      await this.paymentService.charge(orderId);
      completedSteps.push("payment");

      console.log(`Saga успішно завершена для ${orderId}`);
    } catch (error) {
      console.log(`Saga завершилася помилкою: ${error.message}`);

      // Компенсації виконуються у зворотному порядку
      if (completedSteps.includes("payment")) {
        await this.paymentService.refund(orderId);
      }

      if (completedSteps.includes("inventory")) {
        await this.inventoryService.release(orderId);
      }

      if (completedSteps.includes("order")) {
        await this.orderService.cancel(orderId);
      }

      throw error;
    }
  }
}

async function main() {
  const orderService = new OrderService();
  const inventoryService = new InventoryService();
  const paymentService = new PaymentService();

  const saga = new OrderSaga(
    orderService,
    inventoryService,
    paymentService
  );

  await saga.execute("order-100");

  try {
    await saga.execute("order-fail-payment");
  } catch {
    console.log("Помилку оброблено, компенсації виконано");
  }

  console.log(orderService.orders);
  console.log(inventoryService.reservations);
  console.log(paymentService.charges);
}

main().catch(console.error);

Розподілені транзакції

Навіщо потрібні розподілені транзакції

2PC: Two-Phase Commit

Ролі

Фаза 1: prepare

Фаза 2: commit або rollback

Схема 2PC

Переваги 2PC

Основна проблема 2PC: блокування

Відновлення після збою в 2PC

3PC: Three-Phase Commit

Фаза 1: CanCommit?

Фаза 2: PreCommit

Фаза 3: DoCommit

Чим 3PC відрізняється від 2PC

Обмеження 3PC

Saga

Два способи реалізації Saga

Оркестрація

Хореографія

Приклад Saga з оркестратором

Важливі властивості Saga

Ідемпотентність

Повторні спроби

Надійний стан Saga

Тайм-аути та невизначений результат

Чи є Saga атомарною

Порівняння підходів

2PC

3PC

Saga

Як обрати підхід

Типовий життєвий цикл Saga

Типові помилки

Спроба використовувати локальний rollback для всіх сервісів

Вважати тайм-аут доказом невдачі

Повторювати всі операції без обмежень

Не зберігати стан координатора

Вважати компенсацію завжди симетричною

Ігнорувати повторну доставку повідомлень

Відсутність проміжних статусів

Підсумок