Партиция — единица параллелизма и единственное место, где Kafka гарантирует порядок. Разбор с интерактивным симулятором.
Топик в Kafka физически состоит из партиций. Партиция — это упорядоченный, неизменяемый лог записей: новые записи всегда дописываются в конец и получают порядковый номер — оффсет. Оффсет уникален внутри партиции, но не внутри топика: в топике из трёх партиций одновременно существуют три записи с оффсетом 0.
Партиция важна по двум причинам. Первая: порядок гарантирован только внутри партиции. Между партициями никакого порядка нет, и «глобального порядка в топике» в Kafka не существует. Поэтому требование «события одного клиента обрабатываются по порядку» превращается в проектное решение — ключом сообщения делают идентификатор клиента, и все его события попадают в одну партицию.
Вторая: партиция — единица параллелизма чтения. Внутри одной consumer group партицию читает ровно один участник. Значит потолок параллельной обработки равен числу партиций: четыре консьюмера на две партиции означают двух работающих и двух простаивающих.
Отсюда практический способ посчитать число партиций для требований: партиций ≥ целевой RPS × время обработки одного сообщения, плюс запас на рост. Запас нужен потому, что увеличить число партиций на живом топике можно, а уменьшить — нельзя, и само увеличение ломает порядок по ключу: хеш начинает считаться по новому модулю, и записи одного ключа расходятся по разным партициям.
Если обработчиков нужно больше, чем партиций, и порядок не важен, начиная с Kafka 4.2 существует альтернатива — share groups (KIP-932), где участники конкурируют за записи со всех партиций и их число ничем не ограничено.
Разобрать это в симуляторе Интерактивный сценарий: настраиваешь кластер, ломаешь его и смотришь, что происходитСчитайте от целевой пропускной способности и времени обработки одного сообщения, добавляя запас на рост. Увеличить можно, уменьшить — нет.
Увеличить — да. Но записи, уже лежащие в топике, никуда не переедут, а новые записи тех же ключей уйдут в другие партиции, и порядок по ключу будет нарушен.
Как горячий резерв: при падении активного участника ребалансировка отдаст его партиции живому за секунды. Пропускную способность они не увеличивают.