Асинхронность и сообщения: обзор со свободным припоминанием
Подсказки для свободного припоминания через весь асинхронный раздел. Ответь на каждую своими словами сначала — включая механизм и режим отказа — затем открой образец и сравни.
Припоминание бьёт перечитывание. На каждую подсказку скажи или напиши полный ответ по памяти — механизм и сбой, что он предотвращает, — прежде чем открыть образец. Усилие реконструкции и есть то, что закрепляет семантику доставки, outbox и ловушку бэклога.
Реконструируй хребет раздела, не подглядывая: что развязывает очередь и чего это стоит, почему exactly-once — это effectively-once, чем лог отличается от очереди, два стиля координации, как outbox побеждает двойную запись и почему безграничная очередь — латентная катастрофа.
- 01Что развязывает очередь сообщений и чего развязка тебе стоит?
- 02Объясни at-least-once против at-most-once и почему exactly-once на деле effectively-once.
- 03Чем лог отличается от очереди и что это даёт?
- 04Определи хореографию против оркестрации и правило большого пальца, и что добавляют event sourcing/CQRS.
- 05Что такое проблема двойной записи, как outbox её решает и почему согласованность в конечном счёте — проблема UX?
- 06Почему безграничная очередь — латентная катастрофа и что восстанавливает обратную связь?
Если ты смог реконструировать каждый ответ по памяти, ты держишь хребет раздела. Очередь развязывает producer и consumer во времени, превращая синхронную зависимость по доступности в асинхронную по задержке — оплачено семантикой доставки: at-least-once (без потерь, дубли) — безопасный дефолт, а exactly-once — это effectively-once через идемпотентность + дедуп, на котором работают visibility timeout, DLQ и порядок по ключу. Pub/sub рассылает веером, а лог отличается от очереди удержанием сообщений с пер-consumer офсетами, делая реплей/бэкфилл first-class. Многошаговые потоки — хореография (развязано, просто) или оркестрация (сага с состоянием процесса и компенсациями, для сложных потоков), с event sourcing/CQRS на удержанном логе. Outbox побеждает проблему двойной записи, делая изменение состояния и событие одной локальной транзакцией плюс асинхронный relay (никогда не потеряно, возможно дублировано → идемпотентные consumer’ы), а итоговая согласованность в конечном счёте — проблема UX. Наконец, каждой очереди нужна граница, иначе она отмывает краткий затык в долгий бэклог; ты ограничиваешь, сбрасываешь, лимитируешь темп и алармишь на лаг. Нить: на этой глубине ты называешь компромисс до добавления компонента.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.