Очереди, потоки, события
Partition в Kafka: тест с множественным выбором
Суть Синтез с множественным выбором по всему юниту про partition в Kafka — хеширование key, назначение в consumer group, односторонняя дверь количества partition, skew и rebalance.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих через весь юнит. Каждый отражает решение, которое вы принимаете на реальном design-review по Kafka, — не определение для пересказа, а компромисс, который нужно взвесить, прежде чем трогать конфиг топика.
Цель
Убедитесь, что вы связываете воедино хеширование key, назначение в consumer group, одностороннюю дверь количества partition, hot-partition skew и rebalance — синтез, к которому вёл урок.
Викторина
Completed
У топика 8 partition, а в consumer group 12 участников, но lag продолжает расти. В чём настоящее ограничение и что его действительно устраняет?
Heads-up Здесь нет конкуренции, которую нужно блокировать, — каждый partition назначен ровно одному consumer в группе. Лишние просто не получают назначения; они ни за что не борются.
Heads-up Ни один assignor не позволяет двум consumer в одной группе совместно владеть partition. Один consumer на partition — это фундаментальное правило consumer group, а не настройка assignor.
Heads-up Настройка poll помогает consumer, который уже владеет загруженным partition, но не может создать параллелизм, запрещённый количеством partition, — 4 consumer всё равно ничего не получают.
Викторина
Completed
Топик order-events keyed по orderId на 6 partition и отстаёт на пике. Порядок внутри заказа должен сохраняться. Кто-то предлагает увеличить до 12 partition прямо на живом топике. Почему это ловушка и каков senior-ход?
Heads-up Kafka никогда не перемещает существующие записи при увеличении partition — они остаются там, где были записаны. Разрыв в том, что будущие записи для key теперь хешируются в другое место, поэтому история раскалывается на два partition.
Heads-up Kafka упорядочивает внутри partition, никогда не на уровне топика. Как только записи key попадают на два partition, нет глобального порядка, на который можно опереться, поэтому порядок по key реально теряется.
Heads-up Количество partition вообще нельзя уменьшить — оно только растёт. Нет корректного способа слить два упорядоченных лога, поэтому Kafka отказывается; изменение фактически необратимо.
Викторина
Completed
Один consumer в здоровой группе упёрт в 100% CPU и отстаёт, пока пять остальных простаивают. Количество partition и consumer сбалансировано. Что происходит и где исправление?
Heads-up Partition назначены равномерно — дисбаланс в данных, а не в назначении. Rebalance перетасует владение, но горячий key всё равно стечётся в один partition после него.
Heads-up Параллелизм consumer ограничен количеством partition, а один key по-прежнему отображается на один partition. Новые consumer либо простаивают, либо владеют другими partition — ни один не разгрузит единственный горячий key.
Heads-up Настройка fetch помогает незначительно, но не исправит структурный skew, где один partition несёт непропорциональную долю трафика. Узкое место — один key на одном partition.
Викторина
Completed
При обычном rolling-деплое потребление по всей группе останавливается на несколько секунд каждый раз, когда перезапускается под, хотя заменяется только один consumer за раз. В чём причина и что её уменьшает?
Heads-up Пауза охватывает всю группу, а не только новый под, и происходит до любого fetch — это протокол rebalance отзывает и переназначает partition, а не проблема размера fetch.
Heads-up Rebalance consumer переназначает владение partition среди consumer; он не перемещает данные partition между broker. Перемещение реплик — это отдельная операция на стороне broker.
Heads-up Остановка — это сам протокол rebalance, прекращающий потребление, а не нехватка ёмкости координатора. Исправление — это стратегия rebalance (cooperative rebalancing и static membership), а не больше broker.
Викторина
Completed
Команда планирует топик и спрашивает, выделить ли 8 partition под текущую нагрузку или 64 про запас. Какова правильная рамка рассуждения?
Heads-up Partition не бесплатны: каждый добавляет метаданные, файловые дескрипторы и накладные расходы репликации, а слишком много деградируют throughput и удлиняют failover контроллера. Есть реальная верхняя граница, а не только плюсы.
Heads-up Поднять количество partition позже — это односторонняя дверь, которая перехеширует key и ломает порядок по key. Запас закладывают заранее именно чтобы избежать resize на месте.
Heads-up Уменьшить количество partition нельзя никогда, а увеличение имеет серьёзные последствия для порядка. Это одно из наименее обратимых решений в дизайне Kafka.
Викторина
Completed
Producer отправляет записи без key в топик с 6 partition, а нижестоящий consumer полагается на обработку событий одной сущности по порядку. Почему этот дизайн ломается и как исправить?
Heads-up Kafka упорядочивает только внутри одного partition, никогда на уровне топика и никогда по wall-clock времени отправки. Записи без key рассеиваются, поэтому события одной сущности могут перемешаться.
Heads-up Больше partition не привяжет запись без key к одному и тому же — без key у partitioner нечего хешировать, поэтому записи продолжают рассеиваться. Исправление — задать key, а не добавлять partition.
Heads-up Idempotent producer предотвращает дубликаты записи внутри partition; он не co-locate записи без key. Порядок для сущности берётся из keyed на один partition.
Итог
Сквозная линия — один механизм в трёх ролях: hash(key) % N делает распределение, порядок по key и co-location одновременно. Из него следует всё — порядок держится только внутри partition, параллелизм consumer жёстко ограничен количеством partition, а смена N перехеширует key и ломает порядок по key, поэтому количество — это односторонняя дверь, под которую закладывают запас заранее, а не настраивают. Два продакшен-сбоя, hot-partition skew (исправляется на уровне key) и stop-the-world rebalance (укрощаются cooperative rebalancing и static membership), сводятся к одному уроку: key и количество — это и есть реальные решения дизайна, и принимаются они до того, как топик появится.