Очереди, потоки, события
Partition в Kafka: сломать и починить порядок по key
Прочитать, что количество partition — односторонняя дверь, не то же самое, что увидеть, как порядок по key испаряется на собственном кластере. Соберите небольшой пайплайн заказов, докажите, что порядок держится, сломайте его намеренно бампом partition на месте, затем мигрируйте на больший топик безопасным способом — с доказательствами на каждом шаге.
Превратите ментальную модель юнита в воспроизводимый инженерный цикл: keyed топик ради порядка, проверка гарантии, воспроизведение сбоя при increase partition, который её ломает, и выполнение dual-write миграции, сохраняющей порядок, — измеряя lag consumer и корректность порядка на всём пути.
Соберите пайплайн order-events, требующий строгого порядка внутри заказа, продемонстрируйте, что increase partition на месте его ломает, затем безопасно масштабируйте ёмкость через миграцию на новый топик — доказывая каждое утверждение выводом consumer и метриками lag/rebalance, а не словами.
- Baseline-прогон на 6 partition с валидатором порядка, рапортующим ноль нарушений внутри заказа под конкурентной нагрузкой.
- Доказательство (дамп назначения или lag на consumer), что при 8 consumer на 6 partition ровно 2 consumer не владеют partition.
- Воспроизведённое increase partition на месте, показывающее ненулевой счётчик нарушений порядка для перехешированных key, с указанием конкретных orderId и их старого/нового partition.
- Завершённая dual-write миграция на больший топик v2 с нулём нарушений порядка через cutover, плюс снимок lag/rebalance, показывающий, что cutover был контролируемым.
- Абзац-резюме, противопоставляющий resize на месте и миграцию: почему смена modulo ломает порядок и почему миграция сохраняет историю каждого key.
- Вбросьте горячий key (один заказ-кит, несущий 60%+ трафика) и покажите, как один consumer упёрт, пока другие простаивают; затем примените key-salting и покажите, как нагрузка размазывается — и задокументируйте порядок внутри сущности, который вы при этом отдали.
- Переключите группу с eager RangeAssignor на CooperativeStickyAssignor и добавьте стабильный group.instance.id; измерьте длительность rebalance при rolling-перезапуске до и после и сообщите снижение.
- Добавьте Kafka Streams (или stateful) consumer с keyed-по-partition state store и покажите, как increase partition на месте портит его локальное состояние, затем подтвердите, что путь миграции держит store согласованным.
- Прогоните количества partition (6 / 50 / 200) на том же железе и постройте график throughput producer и p99 produce-latency, найдя точку, где больше partition перестают помогать для вашего broker.
Это цикл, который вы запускаете перед любым реальным изменением ёмкости Kafka: keyed ради нужного порядка, доказательство гарантии валидатором, воспроизведение режима сбоя на игрушечном кластере, чтобы вы ему доверяли, и масштабирование через dual-write миграцию на новый топик вместо resize на месте — измеряя lag, rebalance и нарушения порядка на каждом шаге. Увидеть, как порядок по key ломается один раз, намеренно, — вот что делает одностороннюю дверь реальной, а не лозунгом, и превращает безопасную миграцию в мышечную память.