Три ножки сбоя — где реально происходят дубликаты и потери

Три ножки сбоя

Если хочешь понять, где именно проскальзывает дубликат — не в теории, а на какой конкретной границе — вот три места, которые нужно проверить. Зная, какая ножка его породила, сразу понимаешь, какой фикс применять.

Сообщение проходит через три отдельные коммуникационные границы. Каждая граница может упасть так, что производит потерю или дубликат.

Ножка 1 — Producer к брокеру. Producer отправляет сообщение и ждёт ack от брокера. Если сеть роняет send — сообщение не дошло. Если сеть роняет ack — producer никогда не узнает, что сообщение сохранено, и ретраит. Брокер получает то же логическое сообщение второй раз. At-least-once producers ретраят на timeout — это feature, не баг, но это значит, что брокер может видеть одно и то же сообщение несколько раз.

Ножка 2 — Durability брокера. Брокер ack-нул producer, но должен сохранить сообщение до краша. Если существует replication lag при краше брокера, followers могут не иметь сообщения. Правильная конфигурация (Kafka acks=all, SQS надёжность по умолчанию) закрывает эту ножку, но misconfiguration тихо роняет сообщения здесь.

Ножка 3 — Брокер к consumer. Именно здесь происходит большинство production-дубликатов. Брокер доставляет сообщение consumer. Consumer обрабатывает (вызывает Stripe, апдейтит БД), потом отправляет ack. Если consumer падает после обработки, но до ack — у брокера нет записи об успехе. Он передоставляет сообщение следующему consumer. Side effect выполняется дважды.

Все три ножки производят дубликаты, но только ножка 3 делает это после того, как side effect уже выполнился — именно поэтому она приводит к двойным списаниям. Ножки 1 и 2 создают дубликаты или потери ещё до выполнения бизнес-логики, и их проще поглотить конфигурацией брокера. Без идемпотентного consumer ножку 3 не поймать со стороны брокера.

Ножку 3 стоит проследить на уровень глубже, потому что порядок обработки и ack решает, станет ли сбой дубликатом или потерей. Диаграмма ниже идёт по жизненному циклу consume→process→ack и отмечает, где бьёт каждый сбой.

Трасса инцидента двойного списания

Вот точный SQS visibility-timeout сценарий, который ловит инженеров каждые полгода.

1. T=0с: Lambda получает msg-7a3f («списать $50 за заказ O-123»). SQS прячет сообщение от других consumer-ов на visibility timeout (дефолт 30с).
2. T=0.5с: Lambda вызывает Stripe. Stripe списывает карту. charge_id=ch_abc123 возвращён.
3. T=29с: Lambda всё ещё работает (медленная downstream DB-запись). DeleteMessage ещё не вызван.
4. T=30с: SQS visibility timeout срабатывает. msg-7a3f становится visible для всех consumer-ов снова — у SQS нет информации, что первая Lambda преуспела.
5. T=30.1с: Вторая Lambda поднимает msg-7a3f. Вызывает Stripe. Второе списание: ch_xyz789.
6. T=31с: Первая Lambda наконец вызывает DeleteMessage. Сообщение удалено. Но ущерб нанесён: клиент списан $100 за заказ $50.

Сбой — не баг. Это определённое поведение at-least-once delivery, когда visibility timeout короче времени обработки.