Должен ли я добавить буфер после источника Kafka в потоке Akka

Question

Согласно этому сообщению в блоге :

Если источник потока опрашивает внешнюю сущность на наличие новых сообщений и обработка в нисходящем направлении неравномерна, вставка буфера может иметь решающее значение для достижения хорошей пропускной способности. Например, большой буфер, вставленный после Kafka Consumer из библиотеки Reactive Streams Kafka, может повысить производительность на порядок в некоторых ситуациях. В противном случае источник может не опросить Кафку достаточно быстро, чтобы поддерживать поток ниже по потоку, насыщенный работой, при этом источник колеблется между обратным давлением и опросом Кафки.

Документация для alpakka kafka connnector не упоминает об этом, поэтому мне было интересно, имеет ли смысл использовать буфер в этом случае. То же самое относится и к приемникам Kafka (я должен добавить буфер раньше)?

Answer 1

... Мне было интересно, имеет ли смысл использовать буфер в этом случае

Рассмотрим следующий фрагмент из сообщения в блоге, которое вы цитировали:

... последующая обработка неоднородна ....

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

Если обработка, выполняемая в нисходящем направлении от источника коннектора Kafka, является «неоднородной» (т. Е. Она может занимать различное количество времени: иногда обработка происходит быстро, иногда занимает некоторое время), тогда вводится буфер или асинхронная граница может улучшить общую пропускную способность. Это связано с тем, что буфер или асинхронная граница могут позволить источнику продолжать использовать сообщения Kafka, даже если последующая обработка занимает много времени. То есть, если для обработки m1 требуется много времени, источник может принимать сообщения m2, m3 и т. Д. (До тех пор, пока буфер не будет заполнен), не дожидаясь завершения m1. Как утверждает Колин Брек в своем посте:

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

Это потенциальное повышение производительности не распространяется на все ситуации. Снова цитируя Брека:

Аналогично методу async, который обсуждался в предыдущем разделе, следует отметить, что беспорядочная вставка буферов не приведет к повышению производительности и просто потребляет дополнительные ресурсы. Если смежные рабочие нагрузки относительно равномерны, добавление буфера не изменит производительность, поскольку общая производительность потока будет просто зависеть от самой медленной стадии обработки.

Один очевидный способ определить, имеет ли смысл использование буфера (т. Е. .buffer) в вашем случае, - это попробовать его. Вы также можете попробовать добавить асинхронную границу (т.е. .async) вместо этого. Сравните следующие три подхода - (1) поведение слияния по умолчанию без буферизации, (2) .buffer и (3) .async - и посмотрите, какой из них даст наилучшую производительность.