Очереди, потоки, события
Порядок сообщений: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — цена total order по пропускной способности, per-partition FIFO, выбор ordering key, переупорядочивание на продюсере и где порядок тихо ломается в проде.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте — не определение для заучивания, а компромисс, который надо взвесить, когда порядок и пропускная способность тянут в разные стороны.
Цель
Убедись, что связываешь цену total order, per-partition FIFO, выбор ordering key, гарантии продюсера и production-сбои — тот синтез, к которому вёл урок.
Викторина
Completed
Почему глобальный total order по всем сообщениям — это фундаментально налог на пропускную способность, а не флаг конфига, который можно просто включить?
Heads-up Это не стоимость буферизации — это стоимость конкуренции. Упорядочить всё значит сериализовать всё, что упирает тебя в пропускную способность одного consumer'а, сколько памяти ни добавь.
Heads-up Более быстрое железо ускоряет единую точку сериализации, но не распараллеливает её. Потолок структурный — одна partition, один consumer — а не упор в железо.
Heads-up Они различаются именно пропускной способностью. Partial order параллелит по ключам; total order сериализует всё через одну точку. Надёжность — ортогональный вопрос.
Викторина
Completed
Сервис кошелька шлёт credit, затем debit на аккаунт. В staging с одним consumer'ом работало; в проде с восемью consumer'ами debit иногда приходит первым. Что на самом деле изменилось?
Heads-up В consumer group каждая partition назначается ровно одному consumer'у; не все читают все сообщения. Проблема — параллелизм по partition, а не дублирующее чтение.
Heads-up Ничего не потеряно. Оба события доставлены; они обработались не по порядку, потому что попали на partition, которые обслуживают разные consumer'ы параллельно.
Heads-up Переупорядочивание структурное — параллельная обработка независимых partition — а не артефакт задержки. Корневая причина в снятии случайной однопоточности.
Викторина
Completed
Нужен порядок по аккаунту при высокой пропускной способности в Kafka. Какой выбор ordering key верный и почему?
Heads-up Случайный ключ максимизирует параллелизм, но рушит порядок по аккаунту — события одного аккаунта разлетаются по partition и гонятся. Равномерная нагрузка бесполезна, если она ломает нужный порядок.
Heads-up Один ключ направляет каждое сообщение на одну partition: однопоточный конвейер. Это гарантирует total order, но выбрасывает весь параллелизм ради решения задачи на уровне аккаунта.
Heads-up Хеширование timestamp разбрасывает события аккаунта по partition по времени, а не по сущности. Партиционирование — по хешу ключа, не по сортировке; ключ должен быть границей консистентности.
Викторина
Completed
Какая конфигурация продюсера Kafka может тихо переупорядочить два сообщения на одной partition?
Heads-up Это безопасный дефолт со времён KIP-185: брокер отслеживает per-producer, per-partition sequence number (offset продюсера) и отвергает батчи не по порядку, сохраняя порядок даже при 5 in-flight запросах.
Heads-up Один in-flight запрос означает, что более поздний батч не может обогнать переотправляемый, поэтому порядок держится независимо от idempotence.
Heads-up Порядок внутри partition — базовая гарантия Kafka. Он ломается только в конкретном случае неидемпотентного продюсера с несколькими in-flight.
Викторина
Completed
Команда растит топик Kafka с 6 до 12 partition ради пропускной способности и сразу видит порчу порядка по ключу. Почему и как это штатно избегают?
Heads-up Существующие partition не удаляются; их данные остаются. Порча в том, что ключ теперь хешируется на другую partition, чем его уже стоящие в очереди события, поэтому две partition ненадолго держат один ключ.
Heads-up Порядок внутри partition держится после того, как пыль осядет; порча — переходное окно во время переотображения. Устойчивый фикс — избегать частого репартиционирования, а не вечно держать мало partition.
Heads-up Consumer'ы отлично справляются с многими partition. Переупорядочивание идёт от переотображения ключ-в-partition при ресайзе, а не от ёмкости consumer'а.
Викторина
Completed
Сервис профилей потребляет user.updated на at-least-once очереди с конкурентными consumer'ами; обновления одного пользователя иногда приходят не по порядку или дважды. Какой самый сильный дизайн?
Heads-up Идемпотентность не даёт применить одно и то же сообщение дважды, но не упорядочивает два разных сообщения. Два разных обновления одного пользователя всё ещё могут примениться не по порядку; нужна ещё проверка версии.
Heads-up Exactly-once решает дубликаты, а не межсообщенческий порядок между конкурентными consumer'ами. Трактовка её как гарантии порядка — ровно то непонимание, которое отгружает баг.
Heads-up Это гарантирует порядок, сериализуя несвязанных пользователей друг против друга — упёртая пропускная способность ради задачи на уровне пользователя. Верно только для подлинно глобального леджера, которым сервис профилей не является.
Итог
Сквозная линия — одно дерево решений: total order требует единой точки сериализации и упирает пропускную способность, поэтому почти всегда нужен partial order — per-key FIFO. Выбирай partition key как сущность, которая должна оставаться консистентной (accountId, userId). Дальше порядок ломается в трёх предсказуемых местах: неидемпотентный продюсер с несколькими in-flight, репартиционирование, переотображающее ключи, и at-least-once redelivery или DLQ replay. Устойчивый дизайн партиционирует по ключу и version-guard’ит остаточный беспорядок.