Брокеры Kafka ожидают, что в качестве ключей и значений сообщений задействуются байтовые массивы.
Диаграммы Софи Бли-Голдман (Sophie Blee-Goldman) из ее статьи в блоге за май 2020 года «От жаждущего к умному в перебалансировках Apache Kafka» (https://oreil.ly/fZzac).
Другое решение было описано Джесси Андерсоном (Jesse Anderson) в его блоге в статье «У Kafka появился абсолютно новый Poll» (https://oreil.ly/zN6ek).
Другой подход заключается в том, чтобы один потребитель заполнял очередь событий, а несколько рабочих потоков выполняли работу из нее. Пример можно увидеть в статье в блоге Игоря Бузатовича (Igor Buzatoviс́) (https://oreil.ly/uMzj1).
блоге Confluent содержатся предложения о том, как выбрать количество разделов (https://oreil.ly/ortRk) и никогда не добавлять новые разделы.)
Идемпотентный производитель Kafka предотвращает дублирование только в случае повторных попыток, вызванных внутренней логикой производителя. Вызов функции producer.send() дважды с одним и тем же сообщением создаст дубликат, и идемпотентный производитель не предотвратит этого. Это происходит потому, что у производителя нет возможности узнать, что две отправленные записи на самом деле одна и та же запись. Всегда лучше использовать встроенный механизм повторных попыток производителя, чем перехватывать исключения производителя и повторять попытку из самого приложения. Идемпотентный производитель делает этот шаблон еще более привлекательным — это самый простой способ избежать дубликатов при повторных попытках.
Однако время сквозной задержки между конечными пунктами измеряется с момента создания записи до момента, когда она станет доступной для чтения потребителями, и оно одинаково для всех трех вариантов. Причина этого заключается в том, что для поддержания согласованности Kafka не позволяет потребителям читать записи до тех пор, пока они не будут записаны во все синхронизированные реплики. Поэтому, если вам важно время задержки между конечными пунктами, а не только задержка производителя, не нужно искать компромисс — вы получите одинаковое время сквозной задержки между конечными пунктами, если выберете наиболее надежный вариант.
Отдельный сервер Kafka называется брокером (broker)
В некоторых случаях он направляет сообщение в конкретный раздел. Для этого обычно служат ключ сообщения и объект Partitioner, генерирующий хеш ключа и устанавливающий его соответствие с конкретным разделом
Кроме того, разделы могут быть реплицированы, так что на разных серверах будет храниться копия одного и того же раздела на случай выхода из строя одного сервера.
Сообщения в Kafka распределяются по топикам (topics). Ближайшая аналогия — таблица базы данных или каталог файловой системы.