список доступных роутеров для обращения с хранимки от BinaryClusterDiscoveryEndpoint, то TarantoolClient будет держать коннекты ко всем полученным роутерам из списка с верхней границей указываемой в TarantoolClientFactory.createClient().withConnections()?
спасибо за оперативный ответ) то есть connections - это количество соединений которое будет +\- всегда открыто к каждому роутеру из полученного списка?
И тогда еще вопрос, есть ли практический смысл не выдавать весь список доступных роутеров каждому инстансу приложения (если инстансов условно десятки), а выдавать там 3-4 роутера для работы 1 инстанса приложения? Чисто мое предположение, чтобы если разворачивается кластер с большим количеством роутеров инстансов приложения (ну там 30+ к примеру) и не держать на каждом инстансе приложения кучу коннектов ко всем? или лучше играться тогда именно с параметром connections?
Да. Драйвер старается поддерживать такое количество соединений к каждому роутеру
Звучит разумно. Задумывалось так, что пользователи сами реализуют "умный" алгоритм получения адресов роутеров, получая не только их список, но и метаданные например об уровне загрузки каждого роутера или метки, которые определяют к какой группе роутеров надо подключаться
Да,что то похожее я и хочу реализовать🙂 а не подскажете может откуда я могу получить инфу о степени загруженности роутера?ну там текущий rps или количество активных коннектора может быть...
Также с помощью этого механизма предполагается что пользователи реализуют самостоятельно плавное переключение. Т.е. сначала в списке роутеров начинают возвращаться старые и новые ноды, потом только новые ноды, и драйвер самостоятельно переключит запросы и закроет соединения
Можно например брать инфу из metrics - сколько сейчас запросов, или там персентиль смотреть. Готового алгоритма пока нет
Огромное спасибо,этого уже достаточно чтобы реализовать это фичу🙂👍
Это в рамках вот этого обсуждения вчера озвучена идея)
Обсуждают сегодня