Комментарии 11
Интересный факт об архитектуре Apache Kafka заключается в том, что она основана на принципе publish-subscribe (PUB-SUB). Это означает, что большое количество сообщений может быть отправлено производителями (publishers), и эти сообщения могут быть потребляемы многими потребителями (subscribers) одновременно. Это позволяет Apache Kafka обрабатывать огромные объемы данных с высокими скоростями
Звучит, как анекдот:
"Вы работали с Кафкой?"
"Нет, только куфали."
Как правило, продьюсеры создают сообщения для конкретного топика и по умолчанию консьюмеру не важно в какой раздел записывается конкретное сообщение, все сообщения поставляются равномерно во все разделы топика. Хотя в некоторых случаях продьюсер может направить сообщение в конкретный топик.
Наверное должно заканчиваться на: ...продьюсер может направить сообщение в конкретный раздел топика.
Очень "опасный" текст для неокрепшего ума. Есть несколько неточностей, которые могут привести к принципиально неправильному пониманию работы kafka. А ведь идеи, заполненные в ней, очень эстетично и эффективно решают задачи, которые стоят перед разработчиками и потребителями продукта.
Про первую неточность уже написали:
Хотя в некоторых случаях продьюсер может направить сообщение в конкретный топик.
Продюсер обязан указать топик, в который он отправляет сообщение, но может также указать и раздел (партицию, partition) топика.
Ещё один блок, бросившийся в глаза:
здесь ключ не является обязательным и не несет для Kafka никакого смысла
Значение ключа несёт достаточно много смысла для kafka. Это основной признак группировки сообщений и маркер, что сообщения относятся к одной сущности. Через этот маркер работают механизмы распределения сообщений по разделам (partition, партициям), а это важный момент для соблюдения очередности получения сообщений в рамках одной сущности (если, конечно, не пытаться пойти в разрез с заложенной идеологией, сознательно или нет), отсюда же растут ноги у log compaction, и возможному снижению траффика для консьюмера.
Заодно спрошу о проблеме что решаю - а как настройками ограничить одновременно количество/объем передаваемых данных на брокера/консьюмера. Например мне нужно передавать не более 10 сообщений в минуту.
linger.ms и batch.size действуют по принципу кто быстрее достигнет значений а не одновременно. Пробовал poll.size на консьюмере и всякие fetch ... Чтото ничего не помогло. Как пришел поток в 100 с продюсера так и прилетел на консьюмера.
Я не настоящий сварщик, но у кафки есть механизм квот, Kafka Quotas, или как-то так. Квоты позволяют контролировать несколько ресурсов, и, если склероз не изменяет, то запросы чтения и записи среди них.
А можете подробнее пояснить какая у вас проблема, какую задачу вы решаете? Зачем понадобилось лимитировать?
В мире Кафки принято решать все логические вопросы на стороне клиента. Соответственно, вы можете ограничить скорость вычитывания на консьюмере. Но непонятно зачем это нужно.
linger.ms и batch.size нужны для того, чтобы отправлять сообщения не по одному, а батчами. На суммарное количество/объем сообщений от продюссера не влияют.
У нас пока попытка обойтись без сапописных клиентов. Дано - прод база postgres в которую ежедневно но раз в сутки заливается до 10млн записей. Она в режиме логической репликации, далее к ней подключен debezium далее kafka, далее приемник postgres (опять через дебезиум) и потом идут преобразования и аналитика. Идея ограничения в том чтобы избежать пика загрузки. Архитектура от вендора, поменять нереально, только настройка.
Решение вашего вопроса лежит не в плоскости Кафки. Кафка не создана для того чтобы ограничивать потоки, наоборот, ее задача прогонять через себя как можно больше и как можно надежнее.
Из вашего сообщения непонятно где вы хотите избежать пика нагрузки на вторую базу или на вашу систему аналитики и преобразований? Если первое, то ковыряйте настройки debezium. Если не выйдет — придумывайте костыли с дополнительной табличкой в первой базе, куда перекладывайте из первой, например, процедурами. Мне такой подход совершенно не нравится, но это можно реализовать. На крайняк, троттлите сеть. Но лучше, конечно, свой продюсер написать, на котором вы будете контролировать скорость вычитки из базы и записи в Кафку.
Если вы хотите избежать нагрузки на вашу систему обработки. Тогда именно там это и нужно делать. Сделайте так, чтобы ваша система обработки/аналитики не забирала сразу все, а делала это постепенно.
Очередная статья пересказывающая 5-6 первых страниц примерно любой книги по Kafka. Да еще и с ошибками.
Знакомимся с архитектурой Apache Kafka