Очереди, потоки, события
Outbox: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту outbox — разрыв dual-write, фикс одной транзакцией, polling vs CDC relay, доставка at-least-once и операционный налог.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте — не определение для заучивания, а компромисс, который надо взвесить, когда запись и публикация обязаны произойти обе.
Цель
Убедись, что связываешь разрыв dual-write, фикс одной транзакцией, выбор polling vs CDC relay, гарантию at-least-once и операционный налог — тот синтез, к которому вёл урок.
Викторина
Completed
Хендлер делает INSERT заказа, затем kafka.publish('OrderPlaced'). Под нагрузкой pod убивается по OOM после коммита, но до возврата publish. Какой сбой получается и почему try/catch не спасёт?
Heads-up Фантомные события возникают при публикации ДО коммита с последующим откатом. Здесь заказ закоммитился первым, поэтому опасность обратная: реальный заказ, чьё событие потеряно.
Heads-up Вызов publish не завершился, и его in-memory состояние умерло вместе с pod. Нет долговечной записи, что публикация была должна, поэтому ничего не ретраится. Именно эту долговечную запись добавляет outbox.
Heads-up Transaction заказа закоммичена и независима от вызова брокера; более поздний сбой в отдельной системе не может откоммиченное отменить. У двух хранилищ нет общей transaction — это и есть корневая проблема.
Викторина
Completed
Почему запись бизнес-строки и outbox-строки в одной локальной transaction даёт атомарность «бесплатно», а 2PC между Postgres и Kafka — нет?
Heads-up Атомарность даёт не append-only. Она следует из того, что оба INSERT делят одну локальную transaction против одной базы; outbox был бы так же атомарен, даже если бы допускал обновления.
Heads-up Relay работает намного позже в отдельном процессе; он намеренно НЕ в transaction. Атомарность заканчивается на двух локальных INSERT — публикация это отдельный, ретраибельный шаг.
Heads-up 2PC между БД и Kafka не просто сложнее кодить — блокирующий координатор 2PC становится худшей проблемой доступности, чем dual-write, а Kafka не даёт XA-участия, которое хотелось бы в production.
Викторина
Completed
Команда гоняет polling relay с интервалом 1с и хочет, чтобы события прилетали быстрее. Они думают снизить до 25мс. Как это читает senior?
Heads-up Индексный запрос всё равно стоит round trip, планирования и захвата блокировки на первичной каждый тик. Сорок poll в секунду по репликам — реальная, постоянная нагрузка, даже когда таблица пуста.
Heads-up Задержка polling ограничена интервалом, поэтому более тесный интервал её снижает — проблема в стоимости нагрузки, а не в невозможности. CDC — лучший инструмент, когда реально нужно меньше 100мс.
Heads-up CDC tailing WAL и эмитит в момент коммита INSERT, давая задержку в единицы мс с почти нулевой нагрузкой на таблицу — меньше задержки, чем polling, а не больше.
Викторина
Completed
Почему outbox даёт at-least-once, а не exactly-once, и что это навязывает каждому консьюмеру?
Heads-up Idempotent-продюсеры дедупят ретраи в рамках одной сессии продюсера, а не через крах-и-рестарт relay, который перечитывает неотправленную строку. Гарантия outbox — at-least-once сквозная; дедуп — работа консьюмера.
Heads-up Это лишь сдвигает разрыв и превращает восстановимый дубликат в невосстановимое потерянное событие — крах после UPDATE и до publish, и строка выглядит готовой, хотя ничего не отправлено. Publish-then-mark строго безопаснее.
Heads-up At-least-once терпит дубликаты только потому, что консьюмеры их дедупят. Обработка OrderPlaced дважды должна списать карту один раз; идемпотентность — несущая половина паттерна, а не опция.
Викторина
Completed
Ты масштабируешь polling relay с одной реплики до трёх ради пропускной способности и сразу видишь, что каждое событие публикуется примерно трижды. Какой фикс?
Heads-up Outbox прекрасно масштабируется по репликам; нужна лишь координация захвата строк. SKIP LOCKED позволяет нескольким воркерам делить таблицу без пересечений.
Heads-up Смещённые интервалы не мешают двум воркерам выбрать одни и те же WHERE sent=false строки на перекрывающихся тиках. Только захват блокировкой делает батчи непересекающимися.
Heads-up At-least-once терпит редкий дубликат от краха, а не намеренное утроение каждого события; это жжёт пропускную способность и долбит консьюмеров. Координируй relay через SKIP LOCKED.
Викторина
Completed
Outbox-таблица выросла до нескольких сотен тысяч строк, polling-запросы замедляются, а ночной DELETE старых sent-строк вызывает конкуренцию блокировок с вставками. Какой дизайн очистки лучше?
Heads-up Не помечать строки sent заставит relay переотправлять всё вечно — бесконечный шторм дубликатов, а не очистку. Sent-строки надо reaping, просто не одним гигантским DELETE.
Heads-up Больше индексов делают записи — включая горячий путь INSERT и сам DELETE — медленнее, а не быстрее, и не решают конкуренцию блокировок. Батчируй удаления или партиционируй.
Heads-up Привязка очистки к бизнес-записи добавляет задержку и давление блокировок на горячий путь без выгоды. Reaping — фоновое обслуживание, батчируй его или дропай партиции вне основного потока.
Итог
Сквозная линия юнита — одна цепочка: dual-write поперёк двух хранилищ не имеет крах-безопасного порядка, поэтому ты схлопываешь его в одну локальную transaction, которая пишет бизнес-строку и outbox-строку вместе. Отдельный relay шлёт эти строки — polling (просто, но задержка ограничена интервалом и постоянная нагрузка на БД) или CDC (единицы мс, почти нулевая нагрузка на таблицу, ценой операций). Поскольку relay публикует, затем помечает sent двумя шагами, доставка at-least-once, поэтому консьюмеры дедупят по стабильному event id. Операционный налог — bloat таблицы, порядок при параллельных relay, конкурирующие реплики — оплачивается партиционированием, батчевым reaping, keying по aggregate и FOR UPDATE SKIP LOCKED.