Partition в Kafka: тест с множественным выбором
Синтез с множественным выбором по всему юниту про partition в Kafka — хеширование key, назначение в consumer group, односторонняя дверь количества partition, skew и rebalance.
Шесть вопросов, проходящих через весь юнит. Каждый отражает решение, которое вы принимаете на реальном design-review по Kafka, — не определение для пересказа, а компромисс, который нужно взвесить, прежде чем трогать конфиг топика.
Убедитесь, что вы связываете воедино хеширование key, назначение в consumer group, одностороннюю дверь количества partition, hot-partition skew и rebalance — синтез, к которому вёл урок.
У топика 8 partition, а в consumer group 12 участников, но lag продолжает расти. В чём настоящее ограничение и что его действительно устраняет?
Топик order-events keyed по orderId на 6 partition и отстаёт на пике. Порядок внутри заказа должен сохраняться. Кто-то предлагает увеличить до 12 partition прямо на живом топике. Почему это ловушка и каков senior-ход?
Один consumer в здоровой группе упёрт в 100% CPU и отстаёт, пока пять остальных простаивают. Количество partition и consumer сбалансировано. Что происходит и где исправление?
При обычном rolling-деплое потребление по всей группе останавливается на несколько секунд каждый раз, когда перезапускается под, хотя заменяется только один consumer за раз. В чём причина и что её уменьшает?
Команда планирует топик и спрашивает, выделить ли 8 partition под текущую нагрузку или 64 про запас. Какова правильная рамка рассуждения?
Producer отправляет записи без key в топик с 6 partition, а нижестоящий consumer полагается на обработку событий одной сущности по порядку. Почему этот дизайн ломается и как исправить?
Сквозная линия — один механизм в трёх ролях: 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 и количество — это и есть реальные решения дизайна, и принимаются они до того, как топик появится. Теперь, когда ты сидишь на design review по Kafka, ты узнаешь эти шесть вопросов раньше, чем их задаст кто-то другой — и сам спросишь про ключ и количество partition первым.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.