привет, подскажите архитектурные подходы как лучше реализовать следующее:
Есть три инстанса сервиса (docker service scale 3), первая слушает цены по товарам типа А и складывает в локальный кэш, вторая по типу Б, третья С.

на докер сворм сервис приходит рест кол от клиента, купить N штук такого то товара, соответствен через лоад балансер рандомно попадаем на ноду сервиса, а как сделать так что бы попали именно на нужную ноду в кэше которой есть инфа про цены нужного нам товара?

P.S. распределенный кэш типа редис, хэзелкаст не справляется с кол ивентов по обновлению цены товара, загибается на апдейте, лаг растет не вывозим, с локальной конкурентной мапкой или Disruptor дела обстоят лучше и лаг по обновлению цен разгребаем ...

привет! возможно есть здесь ребята, которые работали с redis и webflux на котлине?

Если это инстансы, то предполагается, что они идентичны (иначе load balancer тогда непонятно зачем)
Думаю, надо разделить эти типы и тогда роутить на основании запроса на нужные сервисы

наверняка, но - nometa.xyz

Какая у вас нагрузка на эти ивенты? 100к рпс?

Лоад балансер который стандартный в докер сворм сервисов, разделять на отдельные не хочется вить они делают одну и ту же работу, слушают цены на разные товары и за счёт горизонтального масштабирования легко удается справляется с лагом и держать на каждом инстансе самый актуальный кэш цен

Если доверять Кафка менеджеру то на топике около 61К per sec

неплохо. но редис по идее вполне способен такое выдерживать)

Лаг доходит до 200К, замерял и самое долгое время выполнения это апдейт в редис/хэзелкаст, игрался и с репликацией и т.д. прирост есть но не значительный, на локальной мапке конечно совершено другие показатели

а вы какой драйвер к редису юзали? обычный блокирующий?

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

ну это дополнительный слой балансировки если угодно

акке все равно надо знать куда направлять, а как она это узнает если не будет хранить мапу?))

заведомо знаю все типы месседжи, могу создать акторов на них при бутстрапе

N вообще на балансировщике такое разделение не делают

либо в запросе надо указать явно

ну это попахивает чем то вроде sticky session

на самом деле это попахивает микросервисами и разделением по микросервису на доменную модель

если у вас монолит, то дело не айс, да

что явно указывать в запросе ? запрос http кол который идет к докер сворм сервису с  N контейнерами.
пусть будет так

{
"type": "A", 
"volume": 50  
}

цены по типу А лежат во втором инстансе

при коле на докер сворм сервис round robin алгоритмом попаду на N - сервис на котором в локальном кэше не будет этих данных