Я не могу дать вам однозначного ответа, существует множество шаблонов и ограничений, которые могут повлиять на ответ, но вот некоторые из вещей, которые вы, возможно, захотите принять во внимание:

• Единицей параллелизма является раздел, поэтому, если вы знаете среднее время обработки одного сообщения, вы сможете рассчитать количество разделов, необходимых для поддержки. Например, если для обработки каждого сообщения требуется 100 мс, а вы получаете 5 КБ в секунду, вам понадобится не менее 50 разделов. Добавьте еще процент, чтобы справиться с пиками и переменной производительностью инфраструктуры. Теория массового обслуживания может дать вам математические данные для расчета ваших потребностей в параллелизме.

• Насколько интенсивен ваш трафик и какие у вас ограничения по задержке? Принимая во внимание последний пункт, если у вас также есть требования к задержке, вам может потребоваться масштабировать разделы, чтобы справиться с пиковой скоростью трафика.

• Если вы используете какие-либо шаблоны размещения данных или требуете упорядочения сообщений, вам необходимо учитывать рост трафика в будущем. Например, вы имеете дело с данными клиентов и используете свой идентификатор клиента в качестве ключа раздела и зависите от того, что каждый клиент всегда направляется в один и тот же раздел. Возможно, для поиска событий или просто для обеспечения того, чтобы каждое изменение применялось в правильном порядке. Что ж, если вы добавите новые разделы позже, чтобы справиться с более высокой скоростью сообщений, то теперь каждый клиент, вероятно, будет перенаправлен на другой раздел. Это может вызвать некоторые проблемы с гарантированным упорядочением сообщений, поскольку клиент существует в двух разделах. Итак, вы хотите создать достаточно перегородок для будущего роста. Просто помните, что это легко масштабировать и у потребителей, но перегородки требуют некоторого планирования, так что будьте осторожны и будьте уверены в будущем.

• Наличие тысяч разделов может увеличить общую задержку.

Это зависит от требуемой пропускной способности, размера кластера и технических характеристик оборудования:

Об этом есть четкий блог, написанный Джун Рао из Confluent: Как выбрать количество тем / разделов в кластере Kafka?

Также это может быть полезно для понимания: Apache Kafka поддерживает 200 КБ разделов на кластер

Этот старый тест от соучредителя Kafka довольно приятен для понимания масштабов - https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines

Непосредственный вывод из этого, как и из Vanlightly сказал здесь, заключается в том, что время обработки потребителя является наиболее важным фактором при принятии решения о количестве разделов (поскольку вы не готовы оспаривать пропускную способность производителя).

максимальный параллелизм для потребления - это количество разделов, поэтому вы хотите убедиться, что:

((время обработки одного сообщения в секундах x количество сообщений в секунду) / количество разделов)<< 1

если он равен 1, вы не можете читать быстрее, чем писать, и это без упоминания всплесков сообщений и сбоев \ простоев потребителей. поэтому вам нужно, чтобы оно было значительно ниже 1, насколько оно зависит от задержки, которую может выдержать ваша система.

Перегородки = макс (NP, NC)

где:

NP - количество необходимых производителей, определяемое путем расчета: TT / TP NC - количество требуемых потребителей, определяемое вычислением: TT / TC TT - общая ожидаемая пропускная способность нашей системы. TP - максимальная пропускная способность одного производителя для одного раздела. TC - максимальная пропускная способность одного потребителя из одного раздела.