Очереди, потоки, события
Порядок сообщений: тест на свободное воспроизведение
Воспроизведение бьёт перечитывание. Для каждого промпта скажи или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет материал.
Восстанови ключевые механизмы юнита — total order против partial order, per-partition FIFO, выбор ordering key, опасность переупорядочивания на продюсере и паттерны выживаемости — не подглядывая в урок.
- 01Почему total order по всем сообщениям — налог на пропускную способность, а не бесплатная опция конфига?
- 02Что такое partial order и как его выражают Kafka и SQS FIFO?
- 03Как выбирать ordering key и что идёт не так с типичными плохими выборами?
- 04Как продюсер Kafka может переупорядочить два сообщения на одной partition и как это починили?
- 05Почему корректно партиционированный per-key FIFO поток всё равно может показать события не по порядку и что от этого защищает?
- 06Почему добавление partition в топик Kafka рискует испортить порядок по ключу и как этого избегают?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: total order требует одной точки сериализации и упирает пропускную способность, поэтому тянешься к partial order — per-key FIFO через partition key Kafka или MessageGroupId SQS FIFO. Выбирай ключ как границу консистентности, проверь, что продюсер идемпотентен и не может переупорядочить у источника, и помни, что at-least-once redelivery, DLQ replay и репартиционирование ломают порядок даже при корректном партиционировании. Устойчивый consumer идемпотентен, предпочитает коммутативные эффекты и version-guard’ит устаревшие обновления.