В настоящее время я работаю с Akka Stream Kafka, чтобы взаимодействовать с kafka, и мне было интересно, каковы были различия с Кафкинские потоки.
Я знаю, что подход, основанный на Акке, реализует реактивные спецификации и обрабатывает противодавление, функциональность, которая, по-видимому, отсутствует в потоках кафки.
Каким будет преимущество использования потоков kafka над потоками kkka akka?
Ваш вопрос очень общий, поэтому я дам общий ответ с моей точки зрения.
Во-первых, у меня есть два сценария использования:
Это уже позволяет мне ответить на вопрос о противодавлении: для первого сценария выше есть механизм противодавления в потоках кафки.
Теперь остановимся только на первом описанном выше сценарии. Посмотрим, что я потеряю, если решит прекратить использование потоков Кафки:
Это самые большие различия, которые важны для меня, я надеюсь, что это имеет смысл для вас!
Большое преимущество Akka Stream над потоками Кафки - это возможность реализовать очень сложные графики обработки, которые могут быть циклическими с входом/выводом вентилятора и контуром обратной связи. Потоки Кафки позволяют только ациклический граф, если я не ошибаюсь. Было бы очень сложно реализовать график циклической обработки поверх потоков Kafka
Нашел эту статью, чтобы дать хорошее резюме проблем с распределенным дизайном, которые Kafka Streams предоставляет (дополняет Akka Streams).
https://www.beyondthelines.net/computing/kafka-streams/
порядок сообщений: Kafka сохраняет своего рода файл с добавлением только в том случае, когда он хранит все сообщения. Каждое сообщение имеет идентификатор последовательности, также известный как его смещение. Смещение используется для указания позиции сообщения в журнале. Потоки Kafka используют эти смещения сообщений для поддержания порядка.
разбиение: Kafka разбивает тему на разделы и каждый раздел реплицируется среди разных брокеров. Разделение позволяет распространять нагрузку, а репликация делает приложение отказоустойчивым (если брокер недоступен, данные все еще доступны). Это хорошо для разделения данных, но нам также необходимо распределить процессы аналогичным образом. Kafka Streams использует топологию процессора, которая опирается на управление группой Kafka. Это тот же групповой менеджмент, который используется потребителем Kafka для равномерного распределения нагрузки между брокерами (эта работа в основном управляется брокерами).
Отказоустойчивость: репликация данных обеспечивает отказоустойчивость данных. Управление группой имеет встроенную отказоустойчивость, поскольку она перераспределяет рабочую нагрузку среди оставшихся экземпляров реального брокера.
Управление состоянием: потоки Kafka предоставляют локальное хранилище, резервное копирование с помощью журнала изменений кафки, в котором используется сбой журнала (поддерживается только последнее значение для заданного ключа). Кассовое уплотнение Kafka
Повторная обработка: при запуске новой версии приложения мы можем перерабатывать журналы с самого начала, чтобы вычислить новое состояние, а затем перенаправить трафик на новый экземпляр и выключение старого приложения.
Управление временем: "Данные потока никогда не завершаются и всегда могут выйти из строя", поэтому нужно различать время события и время обработки и правильно его обрабатывать.
Автор также говорит: "Используя этот журнал изменений, Kafka Stream может поддерживать" табличный вид "состояния приложения.
Я считаю, что это относится в основном к корпоративному приложению, где "состояние приложения"... мало.
Для приложения с научными данными, работающего с "большими данными", "состояние приложения", созданное комбинацией обработки данных, моделей машинного обучения и бизнес-логики для организации всего этого, скорее всего, не будет хорошо управляться с помощью Kafka Streams.
Кроме того, я думаю, что использование "исполняемого сценария" чистого функционального события ", например https://github.com/notxcain/aecor, поможет сделать мутации явными и отделить логики приложений из технологии, используемой для управления устойчивой формой состояния посредством принципиального управления мутацией состояния и IO" эффектов" (функциональное программирование).
Другими словами, бизнес-логика не запуталась с Kafka apis.