Комментарии 15
Не понял, в чем асинхронность решения "Разделение микросервисов с помощью асинхронной связи". У вас там все соединено строго последовательно, вы только за счет конвейеров немного увеличили буфер для хранения.
Так, как вы сделали на картинке "Все инстансы микросервиса потребляют все сообщения" лучше не делать. У вас получилось на входе три конвейера и три манипулятора, а пропускная способность этой системы в целом - один манипулятор.
Все инстансы микросервиса потребляют все сообщения— тут скорее буфер изображен, т.к. каждый завод получает уникальную плитку, на самом деле.
а пропускная способность этой системы в целом — один манипулятор.— улучшенный манипулятор может по три предмета за раз переносить, и если скорость изготовления одной шестерни в три раза меньше скорости одного манипулятора на полной загрузке — то норм) Ну и буфер же… ?
каждый завод получает уникальную плитку, на самом деле.
Проблема аналогий Kafka с факторио в том, что плитки - не уникальны.
Какой первичный ключ у плитки?
Потребителям нет разницы, получат они первую плитку от источника или третью.
А еще в Kafka одно и то же сообщение можно прочитать несколько раз разными потребителями. Детальки на заводе в этом смысле "одноразовые".
Kafka следит, чтобы разделы всегда равномерно распределялись между потребителями в каждой группе.
Кажется, в вашей схеме должен быть belt balancer.
Аналогия перестаёт работать при дублировании данных. В Kafka мы можем обработать одну запись несколько раз. Несколько групп потребителей могут потреблять одни и те же записи. Для надёжности темы можно хранить с коэффициентом репликации три. У тем может быть период хранения, по истечении которого записи удаляются. Всё это возможно, потому что записи легко дублировать, в отличие от физических объектов в Factorio.
Если проводить аналогии с kafka, то в качестве данных логично было бы считать физические объекты в factorio, после строительства (аналог получения сообщения от продьюсера) они занимают фиксированное место на плоскости (логи), могут быть разрушены кусаками (retention) и к ним могут подключить ограниченное количество других приспособлений (соответствие количества партиций - консьюмерам). Можно пофантазировать на тему того, что KTable и собратья - это аналог хранилищ внутри печей, к примеру :-)
Стратегия по умолчанию не в том, чтобы разделы всегда распределялись между потребителями равномерно, а в том, чтобы разделы с одинаковыми номерами (из разных топиков) были назначены одному и тому же потребителю.
1) в 2021 появились в кафке какие способы чтобы прям из сайта получать поток из кафки ? без звена в виде прослойки бэкенд сервиса
2) больше вопрос к @arvitaly он походу разбирается , при оконной агрегации появилась фича чтобы только финальный результат агрегации показывался\отправлялся в топик?
способы чтобы прям из сайта получать поток из кафки
Это вообще не вписывается в её концепцию она не про доставление сообщений пользователям, это поток данных для сервисов, потенциально огромный поток данных.
Я не могу представить такой юзкейс когда пользователю нужно получать столько данных что единственный выход — kafka.
1) Если вопрос в том, появился ли в kafka http/websocket/whatever-web интерфейс, то нет, и никогда не появится, это явный overhead желаний по отношению к брокеру сообщений. Посмотрите в сторону rethinkdb.
2) Вы можете с помощью подключенного консьюмера делать что угодно, аггрегировать и становясь продьюсером посылать результат в новый топик.
ДА, аналогия прекрасная. Cам играл и также думал. Вот только есть один моментик которого в кафке очень не хватает. Управление backpreassure(обратное давление). Eсли консюмеры не успeвают обрабатывать сообщения, то продюсеры об этом никогда не узнают и будут пихать в кафку пока не кончится память а дальше просто посыпятся ошибки. В отличии от факторио где к примеру печи отключаются если на ленте нет места.
В отличии от факторио где к примеру печи отключаются если на ленте нет места.
Сначала наполняется сама печь а потом останавливается производство. В переносе на реальный проект с кафкой это бы выглядело так — продюсер наполняет свой внутренний буфер а потом просто стопает процесс в проде(перестает реагировать на события приводящие к генерации сообщений). Не думаю что это бы выглядело адекватно.
Я не про внутренний буфер а про механизм оповещения продюсеров. В переводе на кафку это выглядело бы так - продюсер пытается записать в кафку и получает сигнал что топик переполнен. Далее продюсер останавливает производство месседжей пока кафка не прислала сигнал что можно продолжать. На сколько знаю сейчас такого механизма в кафка нет и продюсер в лудшем случае будет делать ретрай с увеличивающимся по экспоненте таймаутом, а в худшем будет просто продолжать слать меседжы и засорять трафик
Потому что кафка это не про пересылку объекта получателю, а про публикацию и возможность прочитать. Принципиально другая идеология. Со своими плюсами и минусами.
Backpreassure может быть самодельное, второй топик, куда потребитель пишет статус.
Зато тут может быть "из коробки" подход, когда новый запрос на ту же тему просто перетирает старый неактуальный. Через компактизацию топиков по ключу.
Объяснение Kafka на примерах из Factorio