Понимание того, как Akka обеспечивает обратное давление

Итак, у нас есть вариант использования в наших производственных системах, где мы, вероятно, могли бы использовать потоки Akka. Чтобы понять, как потоки Akka обеспечивают обратное давление, я хотел бы углубиться в наши требования.

У нас есть кластер Solr, в котором хранятся некоторые наши данные. Затем у нас есть приложение Play, которое обслуживает интерфейсный сайт, ориентированный на клиентов. Каждый входящий запрос в конечном итоге сводится к получению большого количества данных из Solr с использованием _ 1_ обработчик, который предоставляет Solr. Как только мы получаем весь набор данных из Solr, мы записываем его обратно после морфинга в кластер Cassandra. Это может быть преобразовано в проблему, которую можно решить с помощью потоков Akka, где поток Solr из обработчика /sql будет akka Source, а хранилище Cassandra будет Sink, а все, что между ними, будет настраиваемым Flows.

Я изучал потоки Akka и понял, что это реализация реактивных потоков. В частности, то, как потоки Akka обеспечивают обратное давление, чтобы гарантировать, что производитель не перегружен потребителем. Теперь, что касается моего варианта использования, я хочу понять, как Akka обеспечивает обратное давление.

Насколько я понимаю, есть библиотека реактивных потоков для Cassandra. Поскольку в нашем случае это потребитель, этот драйвер сможет сигнализировать производителю о том, сколько данных он сможет получить. Это означает, что на стороне производителя должен быть соответствующий драйвер, который может реагировать на этот сигнал и управлять излучением элементов. В частности, поскольку производителем в нашем случае является Solr, разве не правильно, что мне также придется использовать совместимый с реактивностью драйвер Solr, который я могу использовать для извлечения документов из Solr и потоковой передачи их в моем приложении? Затем этот драйвер сможет управлять скоростью, с которой он должен получать документы из кластера Solr всякий раз, когда реактивный драйвер Cassandra сигнализирует ему о противодавлении. Это не так?

Если это действительно так, принесет ли использование потоков Akka без нереактивного драйвера на стороне производителя какие-либо преимущества? В частности, существуют ли другие способы, которыми издатели Akka могут предоставить возможности противодавления в таких случаях, когда драйвер не соответствует требованиям к реактивности?


person gravetii    schedule 20.09.2020    source источник
comment
Короче говоря, это возможно путем реализации реактивного расширения для sorl. Вся логика потоков akka может быть определена в одном GraphStage см. docs < / а>   -  person Ivan Stanislavciuc    schedule 20.09.2020


Ответы (1)


Для Solr также существует полностью реактивная реализация Akka Streams из Alpakka project, поэтому использование этого параметра в качестве Source будет обрабатывать противодавление, хотя это будет означать отказ от использования интерфейса SQL для выражения запроса.

С другой стороны, поскольку интерфейс Solr SQL по сути является фасадом JDBC, который использует Solr, можно использовать Интеграция с Alpakka Slick, если вы определяете экземпляр slick.jdbc.JdbcProfile, который использует драйвер JDBC Solr.

person Levi Ramsey    schedule 20.09.2020
comment
Я знаю про библиотеку. Я спрашиваю, что происходит, когда вы используете потоки Akka без реактивного драйвера на стороне производителя. - person gravetii; 21.09.2020
comment
Что ж, это не будет работать без чего-то, что делает Source реактивным (что в основном означает основанное на вытягивании: Sink запрашивает данные, а этапы восходящего потока предоставляют данные или завершают поток, если они не могут предоставить больше ничего). Тем не менее, все, что можно итерировать, можно довольно легко преобразовать в Source (например, с помощью Source.fromIterator). - person Levi Ramsey; 22.09.2020