Повторные попытки, порядок и обратное давление — Примеры

Пример 1 — Сообщение, которое падает дважды

Потребитель платежей вызывает шлюз, который начал отказывать в соединениях, а настроен на три попытки и очередь недоставленных сообщений. Проследите это сообщение по попыткам и скажите, где оно окажется.

политика повторов
  попыток: 3
  задержка: около 1с, затем около 2с, со случайностью
  исчерпаны -> payments.dead-letter

попытка 1  не удалась: connection reset

Решение

попытка 1  08:00:00  не удалась  connection reset
            задержка около 1с, со случайностью
попытка 2  08:00:02  не удалась  connection reset
            задержка около 2с, со случайностью
попытка 3  08:00:05  не удалась  connection reset
            попытки исчерпаны -> направлено в payments.dead-letter

08:00:05  payments.dead-letter  глубина 1   <- оператор может это увидеть и настроить алерт
времена и длительности приведены для примера

Задержка не даёт третьей попытке прийти в тот же момент, что и первая, и даёт восстанавливающемуся шлюзу передышку; предел же попыток не даёт вечно падающему сообщению повторяться бесконечно. Третья попытка — ещё и точка невозврата: с очередью недоставленных сообщение попадает туда, где оператор может его осмотреть, вместо того чтобы пропасть или заблокировать все сообщения за собой. Обычно ошибаются, повторяя немедленно и без предела, — так одно плохое сообщение превращает раздел в тот, который никогда не опустеет.

Пример 2 — Порядок, который не выживает при круговой раздаче

Три события одного заказа — created, paid, shipped — опубликованы без ключа по четырём разделам и четырём потребителям. В журнале потребителя видно, что shipped обработано раньше created, и нижестоящая машина состояний это отвергает. Сохраните порядок связанных событий, не отказываясь от параллелизма.

разделов: 4   потребителей: 4   ключ: нет (круговая раздача)
order.8842.created  -> раздел 2
order.8842.paid     -> раздел 0
order.8842.shipped  -> раздел 3
наблюдается: для некоторых заказов shipped обработано раньше created

Решение

разделов: 4   потребителей: 4   ключ: идентификатор заказа

раздел 0: order.8842.created -> order.8842.paid -> order.8842.shipped
раздел 2: order.8843.created -> order.8843.paid

потребителей: 4   (пятый не добавит параллелизма, пока не добавлены разделы)
именно ключ заставляет связанные события попасть в один раздел, а порядок
внутри раздела — единственный порядок, который журнал обещает.

Порядок гарантирован внутри раздела, поэтому исправление — ключ, который кладёт все события одного заказа в один поток, тогда как разные заказы по-прежнему идут параллельно по разным разделам. Число полезных потребителей ограничено числом разделов, поэтому пропускную способность даёт добавление разделов, а не потребителей. Однако обычно ошибаются, добавляя потребителей сверх числа разделов и ожидая большего параллелизма: это покупает процессы, которые простаивают, и оставляет ошибку порядка на месте.