Дизайн Kafka, потребитель (Consumer)
Потребитель Kafka работает, отправляя запросы «выборки» брокерам, ведущим разделы, которые он хочет использовать. Потребитель указывает свое смещение в журнале с каждым запросом и получает обратно кусок журнала, начиная с этой позиции. Таким образом, потребитель имеет значительный контроль над этой позицией и может перемотать ее, чтобы при необходимости повторно использовать данные.
Push vs. pull
Первоначальный вопрос заключается в том, должны ли потребители получать данные от брокеров или брокеры должны передавать данные потребителю. В этом отношении Kafka следует более традиционному дизайну, разделяемому большинством систем обмена сообщениями, где данные отправляются брокеру от производителя и извлекаются от брокера потребителем. Некоторые системы, ориентированные на ведение журналов, такие как Scribe и Apache Flume, используют совершенно другой путь, основанный на push, когда данные отправляются вниз по потоку. У обоих подходов есть свои плюсы и минусы. Однако система на основе push-уведомлений имеет трудности с взаимодействием с различными потребителями, поскольку брокер контролирует скорость передачи данных. Обычно цель состоит в том, чтобы потребитель мог потреблять с максимально возможной скоростью; к сожалению, в системе push это означает, что потребитель оказывается перегруженным, когда скорость его потребления падает ниже скорости производства (по сути, атака отказа в обслуживании). Система на основе вытягивания (pull) имеет более приятное свойство: потребитель просто отстает и догоняет, когда может. Это можно смягчить с помощью какого-либо протокола отсрочки передачи, с помощью которого потребитель может указать, что он перегружен, но добиться того, чтобы скорость передачи полностью использовалась (но никогда не использовалась чрезмерно), потребителю сложнее, чем кажется. Предыдущие попытки построения систем таким образом привели к более традиционной модели вытягивания.
Еще одно преимущество системы на основе вытягивания (pull-based) заключается в том, что она позволяет агрессивно группировать данные, отправляемые потребителю. Система на основе push-уведомлений должна выбрать либо немедленную отправку запроса, либо накопление дополнительных данных, а затем отправку их позже, не зная, сможет ли нижестоящий потребитель немедленно обработать его. При настройке на низкую задержку это приведет к отправке одного сообщения за раз только для того, чтобы передача все равно буферизовалась, что является расточительным. Дизайн на основе вытягивания исправляет это, поскольку потребитель всегда вытягивает все доступные сообщения после своей текущей позиции в журнале (или до некоторого настраиваемого максимального размера). Таким образом достигается оптимальная пакетная обработка без ненужных задержек.
Недостаток наивной системы, основанной на вытягивании, состоит в том, что, если у брокера нет данных, потребитель может завершить опрос в замкнутом цикле, фактически ожидая прибытия данных. Чтобы избежать этого, есть параметры в pull запросе, которые позволяют запросу потребителя заблокироваться в «длинном опросе» ("long poll"), ожидая прибытия данных (и, возможно, ожидая, пока не станет доступно заданное количество байтов, чтобы гарантировать большие размеры передачи).
Вы можете представить себе другие возможные конструкции, которые были бы только pull, сквозными. Производитель будет локально писать в локальный журнал, и брокеры будут извлекать из него данные, а потребители извлекают из них. Часто предлагается аналогичный тип производителя "store-and-forward". Это интригует, но это предполагается не очень подходящим для целевых сценариев использования, которые имеют тысячи производителей. Опыт масштабной эксплуатации систем с постоянным хранением данных привел к выводу, что включение тысяч дисков в систему во многих приложениях на самом деле не сделает вещи более надежными и станет кошмаром для работы. И на практике обнаружилось, что можно запустить конвейер с сильными SLA в большом масштабе без необходимости постоянства производителя.
Читайте также:
Комментарии
Отправить комментарий