Темы, разделы и ключи

Я ищу некоторые разъяснения по этому вопросу. В документах Kafka я нашел следующее:

Kafka предоставляет только общий порядок над сообщениями внутри раздела, а не между разными разделами в теме. Для большинства приложений достаточно упорядочивания на уровне раздела в сочетании с возможностью разделения данных по ключу. Однако, если вам требуется общий порядок сообщений, это может быть достигнуто с помощью темы, которая имеет только один раздел, хотя это будет означать только один потребительский процесс для каждой группы потребителей.

Итак, вот мои вопросы:

Означает ли это, что если я хочу иметь более одного потребителя (из той же группы), который читается из одной темы, мне нужно иметь более 1 раздела?
Означает ли это, что мне нужно столько же разделов, сколько количество потребителей для одной и той же группы?
Сколько пользователей может читать из одного раздела?

Также есть некоторые вопросы относительно отношений между ключами и разделами в отношении API. Я только посмотрел API-интерфейсы .net(особенно один из MS), но выглядит как похожий Java API. Я вижу, что при использовании производителя для отправки сообщения в тему есть ключевой параметр. Но когда потребитель читает из темы, есть номер раздела.

Как пронумерованы разделы? Начиная с 0 или 1?
Какая именно связь между ключом и разделом? Как я понимаю, какая-то функция на ключе определит раздел. это правильно?
Если у меня есть 2 раздела в теме и вы хотите, чтобы некоторые конкретные сообщения переходили на один раздел, а другие сообщения переходили на другой, я должен использовать конкретный ключ для одного определенного раздела, а остальное для другого?
Что делать, если у меня есть 3 раздела и один тип сообщений на один конкретный раздел, а остальные - на другие 2?
Как обычно я отправляю сообщения на определенный раздел, чтобы узнать, кто из читателей читает? Или мне лучше с несколькими темами?

Спасибо заранее.

Ответ 1

Игорь,

Разделы увеличивают параллельность темы Кафки. Любое количество потребителей/производителей может использовать один и тот же раздел. Это до прикладного уровня, чтобы определить протокол. Кафка гарантирует доставку. Что касается API, вы можете посмотреть на документы Java, поскольку они могут быть более полными. Исходя из моего опыта:

Разделы начинаются с 0
Ключи могут использоваться для отправки сообщений в один и тот же раздел. Например, хеш (ключ)% num_partition. Логика подключается к производителю. https://kafka.apache.org/090/javadoc/index.html?org/apache/kafka/clients/producer/Partitioner.html
Да. но будьте осторожны, чтобы не получить какой-то ключ, который приведет к "выделенному" разделу. Для этого вы можете иметь отдельную тему. Например, управлять темой и темой данных
Кажется, это тот же вопрос, что и 3.
Я считаю, что потребители не должны делать предположения о данных на основе раздела. Типичный подход - иметь группу потребителей, которая может читать несколько разделов темы. Если вы хотите иметь выделенные каналы, лучше (безопаснее/поддерживать) использовать отдельные темы.

Ответ 2

Означает ли это, если я хочу иметь более 1 потребителя (из того же группа) чтение из одной темы мне нужно иметь более 1 раздела?

Давайте посмотрим на следующие свойства кафки:

каждый раздел потребляется ровно одним потребителем в группе
один потребитель в группе может использовать более одного раздела
количество потребительских процессов в группе должно быть & lt; = число перегородок

Благодаря этим свойствам kafka может предоставить как ordering guarantees, так и load balancing через пул пользовательских процессов.

Чтобы ответить на ваш вопрос, да, в контексте той же группы, если вы хотите иметь N consumers, вы должны иметь at least N partitions.

Означает ли это, что мне нужно такое же количество разделов, как и количество потребителей? для той же группы?

Я думаю, что это было объяснено в первом ответе.

Сколько потребителей могут читать с одного раздела?

number of consumers, который может читать из одного раздела, всегда равен number of consumer groups, подписавшемуся на эту тему.

Связь между ключами и разделами в отношении API

Во-первых, мы должны понимать, что producer отвечает за выбор записи, которую следует назначить тому или иному разделу в теме.

Теперь давайте посмотрим, как продюсер делает это. Сначала давайте посмотрим определение класса ProducerRecord.java:

public class ProducerRecord<K, V> {

    private final String topic;
    private final Integer partition;
    private final Headers headers;
    private final K key;
    private final V value;
    private final Long timestamp;

}

Здесь поле, которое мы должны понять из класса, - partition.

Из документов,

Если указан допустимый partition number, этот partition будет использоваться при отправке записи.
Если раздел не указан, но присутствует key, раздел будет выбран с помощью hash of the key.
Если ни key, ни partition нет, раздел будет назначен в round-robin fashion.