Согласованность: транзакции, идемпотентность, outbox и саги

01ACID и уровни изоляции

Транзакция в базе группирует изменения так, чтобы они вместе либо выполнились, либо нет. ACID описывает это обещание: Atomicity (всё или ничего), Consistency (ограничения соблюдаются), Isolation (параллельные транзакции не видят недоделанную работу друг друга) и Durability (закоммиченные данные переживают сбой). Изоляция бывает разных уровней. Read committed, уровень по умолчанию в PostgreSQL, показывает только закоммиченные данные, но позволяет значению измениться между двумя чтениями в одной транзакции. Repeatable read даёт стабильный снимок — это уровень по умолчанию в MySQL InnoDB. Serializable заставляет параллельные транзакции вести себя так, будто они выполнялись одна за другой, ценой повторов при конфликтах. Классические аномалии — потерянные обновления (два пользователя одновременно уменьшают остаток) и write skew. Предотвращайте их блокировками строк (SELECT ... FOR UPDATE), атомарными обновлениями (SET stock = stock - 1 WHERE stock > 0), уникальными ограничениями или уровнем serializable с повтором.

02Почему распределённые транзакции — это сложно

Когда заказ затрагивает вашу базу, платёжного провайдера и очередь сообщений, никакая одна транзакция не охватывает все три. Двухфазный коммит (2PC) пытается: координатор просит каждого участника подготовиться, а затем закоммитить. В некоторых закрытых системах это работает, но блокируется при отказе координатора, держит блокировки на время сетевых round-trip'ов и не поддерживается большинством очередей и ни одним сторонним HTTP API. Фундаментальная проблема — двойная запись: вы сохраняете заказ, а затем публикуете «заказ создан». Если процесс упадёт между этими шагами, то либо событие потеряется, либо — если вы публикуете первым — появится событие для заказа, который так и не сохранился. Повторы добавляют ещё одну проблему: таймаут не говорит, выполнила ли другая сторона работу. Эти сбои нельзя устранить, поэтому вы проектируете с расчётом на них.

• Таймаут означает «неизвестно», а не «не удалось».
• Каждый шаг через границу должен быть повторяемым без побочных эффектов.
• Держите путь сверки для состояний, которые нельзя определить автоматически.

03Ключи идемпотентности

Операция идемпотентна, если её двойное выполнение даёт тот же эффект, что и однократное. GET, PUT и DELETE идемпотентны по определению; POST, который создаёт сущности или списывает деньги с карт, — нет. Решение — ключ идемпотентности: клиент генерирует уникальный ID (UUID) для каждой логической операции и отправляет его, обычно в заголовке Idempotency-Key. Сервер сохраняет ключ вместе с результатом в той же транзакции, что и саму работу, под защитой уникального ограничения в рамках tenant'а или пользователя. Повтор с тем же ключом возвращает сохранённый результат, а не повторяет действие; параллельный дубликат упирается в уникальное ограничение и ждёт или аккуратно падает. Ключи должны истекать через разумный срок, а ключ, повторно использованный с другим телом запроса, должен отклоняться. Ту же идею применяйте к consumer'ам: записывайте ID обработанных сообщений.

1CREATE TABLE idempotency_keys (
2  tenant_id     uuid        NOT NULL,
3  key           text        NOT NULL,
4  request_hash  text        NOT NULL,
5  response      jsonb,
6  created_at    timestamptz NOT NULL DEFAULT now(),
7  PRIMARY KEY (tenant_id, key)
8);
9 
10-- Inside the same transaction as the business write:
11INSERT INTO idempotency_keys (tenant_id, key, request_hash)
12VALUES ($1, $2, $3)
13ON CONFLICT (tenant_id, key) DO NOTHING
14RETURNING key;
15-- No row returned? It is a retry: load and return the stored response.

04Transactional outbox

Паттерн outbox решает проблему двойной записи. Вместо прямой публикации в брокер вы вставляете событие в таблицу outbox в той же транзакции, что и бизнес-изменение. Либо закоммитится и то и другое, либо ничего. Затем отдельный процесс-ретранслятор читает неопубликованные строки, публикует их в очередь или брокер и помечает как отправленные. Если ретранслятор упадёт после публикации, но до пометки, событие опубликуется ещё раз, так что доставка — at-least-once, и consumer'ы должны быть идемпотентными. Используйте FOR UPDATE SKIP LOCKED, чтобы несколько воркеров-ретрансляторов делили работу без коллизий, и подчищайте старые опубликованные строки. Альтернативный ретранслятор — change data capture (например, Debezium, читающий лог базы), который избавляет от поллинга. Обратный паттерн, inbox, хранит ID входящих сообщений для дедупликации на стороне consumer'а.

1BEGIN;
2UPDATE orders SET status = 'paid' WHERE id = $1;
3INSERT INTO outbox (aggregate_id, type, payload)
4VALUES ($1, 'order.paid', $2);
5COMMIT;
6 
7-- Relay worker, in a loop:
8SELECT id, type, payload
9FROM outbox
10WHERE published_at IS NULL
11ORDER BY created_at
12LIMIT 100
13FOR UPDATE SKIP LOCKED;
14-- publish each row, then:
15UPDATE outbox SET published_at = now() WHERE id = ANY($1);

05Саги: оркестрация и хореография

Сага — длинная бизнес-транзакция, разбитая на локальные шаги, у каждого из которых есть компенсирующее действие, семантически отменяющее его. Оформление заказа может выглядеть так: зарезервировать товар, списать деньги с карты, создать отправку. Если списание не удалось, сага снимает резерв. Компенсация — это не откат: отправленное письмо не «разотправишь», поэтому вы шлёте исправление; захваченный платёж возвращают, а не стирают. При хореографии каждый сервис слушает события и порождает следующее («StockReserved» запускает оплату). Это слабо связано, но трудно отслеживать, когда шагов много. При оркестрации один компонент — явная машина состояний — говорит каждому участнику, что делать, и записывает прогресс. Это проще мониторить, тестировать и менять, и для процессов больше чем из двух-трёх шагов это мой вариант по умолчанию. В любом случае сохраняйте состояние саги, делайте каждый шаг идемпотентным и показывайте операторам зависшие саги.

06Eventual consistency, мифы об exactly-once и CAP

Eventual consistency означает, что если новых изменений не поступает, все копии данных в итоге сойдутся, но какое-то короткое время они могут расходиться. На практике это нормально для баллов лояльности, появившихся на секунду позже, и не нормально для баланса, который пользователь может перерасходовать. Проектируйте пользовательский опыт с учётом этого: показывайте состояния «в обработке», читайте свои записи из primary и регулярно сверяйтесь с источником правды, например с отчётом платёжного провайдера. «Exactly-once доставка» по сети — миф; построить можно exactly-once эффект — из at-least-once доставки плюс идемпотентной обработки. CAP простыми словами: когда сеть разрезает вашу систему надвое, каждая половина должна либо отказывать в части запросов (выбор согласованности), либо продолжать отвечать, возможно, устаревшими данными (выбор доступности). Без разделения сети реальный компромисс — задержка против согласованности.

07MVCC, serializable-изоляция и циклы ретраев

PostgreSQL и MySQL InnoDB используют multi-version concurrency control: писатели создают новые версии строк, а читатели видят снапшот, поэтому чтения не блокируют записи. Отсюда и аномалии: две транзакции могут каждая прочитать снапшот, принять решение и записать, не видя друг друга. Уровень serializable в PostgreSQL использует Serializable Snapshot Isolation: он отслеживает read-write зависимости и прерывает одну из транзакций с SQLSTATE 40001 (serialization_failure), когда складывается опасный паттерн. Это даёт самую сильную гарантию без блокировки каждой строки, но только если приложение повторяет всю транзакцию при 40001 — в идеале с небольшим backoff и лимитом попыток. Держите serializable-транзакции короткими, избегайте внешних вызовов внутри них и используйте их для инвариантов, охватывающих несколько строк, например «хотя бы один дежурный врач», где простой блокировки строки недостаточно.

1async function withSerializableRetry<T>(fn: (tx: Tx) => Promise<T>, attempts = 5): Promise<T> {
2  for (let i = 1; ; i++) {
3    try {
4      return await db.transaction(fn, { isolationLevel: "serializable" });
5    } catch (err: any) {
6      const retryable = err?.code === "40001" || err?.code === "40P01"; // serialization / deadlock
7      if (!retryable || i >= attempts) throw err;
8      await new Promise((r) => setTimeout(r, Math.random() * 50 * i));
9    }
10  }
11}

08Идемпотентность в деталях: запросы в процессе и отпечатки

У наивной таблицы идемпотентности есть дыра: первый запрос ещё выполняется, когда приходит ретрай. Храните вместе с ключом состояние: in_progress, затем completed с ответом или failed с флагом retryable. Ретрай, который видит in_progress, получает 409 Conflict (или ненадолго ждёт), но никогда не второе выполнение. Снимайте отпечаток запроса (метод, путь, канонический хэш тела) и отклоняйте повторное использование ключа с другим отпечатком. Решите, что хранить: финальный успех и детерминированные ошибки валидации проигрываются повторно, а временные ошибки вроде таймаута нижестоящего сервиса не кэшируются, чтобы клиент мог повторить запрос. Ограничивайте область ключей аккаунтом, чтобы избежать коллизий, удаляйте их после окна ретраев клиента, а когда операция вызывает третью сторону, передавайте ей производный idempotency key, чтобы вся цепочка была безопасной от начала до конца.

• Состояния: in_progress, completed (с ответом), failed.
• Тот же ключ + другое тело = 422, а не повтор.
• Передавайте производный ключ платёжным провайдерам и другим API.

09Outbox в масштабе: порядок, CDC и слоты репликации

Polling relay с SKIP LOCKED прост, но может переставлять события местами, потому что несколько воркеров публикуют параллельно. Если потребителям нужен порядок по сущности, разделите работу по aggregate ID или используйте один relay на партицию и добавляйте в каждое событие версию агрегата, чтобы потребители могли отбрасывать устаревшие. Инструменты change data capture, например Debezium, читают write-ahead log через logical replication slot вместо опроса — это даёт низкую latency и порядок коммитов. Эксплуатационная ловушка: слот репликации удерживает WAL на primary, пока потребитель его не подтвердит. Если CDC-коннектор остановится, WAL копится и может заполнить диск. Мониторьте lag слотов, задайте max_slot_wal_keep_size (PostgreSQL 13+) как предохранитель и удаляйте брошенные слоты. Регулярно чистите таблицу outbox, в идеале по партициям, чтобы она оставалась маленькой и быстрой.

1-- How much WAL each replication slot is holding back
2SELECT slot_name, active,
3       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained
4FROM pg_replication_slots;
5 
6-- postgresql.conf: never let a stuck slot fill the disk
7-- max_slot_wal_keep_size = '20GB'

10Дизайн саги: pivot-шаги и контрмеры для изоляции

Саги жертвуют изоляцией: другие транзакции могут видеть промежуточные состояния, например зарезервированный товар для заказа, который будет отменён. Упорядочивайте шаги осознанно. Сначала идут компенсируемые шаги (резерв товара, холд средств), затем pivot-шаг — точка невозврата, например capture платежа, а затем повторяемые шаги, которые обязаны в итоге выполниться (создание отправки, отправка чека) и ретраятся, а не компенсируются. Чтобы ограничить аномалии, используйте контрмеры. Semantic lock помечает записи как pending, чтобы другие процессы обращались с ними осторожно. Коммутативные обновления (прибавление и вычитание балансов) делают порядок неважным. Повторное чтение значения перед обновлением показывает, что оно изменилось. Поля версий отклоняют устаревшие записи. Сохраняйте состояние саги с таймаутами на каждый шаг, чтобы сага, вечно ждущая потерянного ответа, становилась видимой задачей, с которой можно работать, а не тихой утечкой зарезервированного товара.