в 10 шардов, есть 10 инстансов микросервисов, которые с ним работают. Нужно сделать так чтобы каждый инстанс микросервиса работал с отдельным шардом и запросы на инстансы распределялись согласно ключу шардирования при помощи некоего балансировщика, который представлен скажем в 3-х инстансах.
Существуют ли уже готовые решения-балансировщики, которые умеют это делать?
Насколько я понимаю, replicaset так и работает. Запросы можно направлять на любой инстанс, он сам разберётся.
А тут поинт в том, чтобы иметь возможность в каждом инстансе микросервиса зафигачить InMemory кэш
Полагаю, что нужно знать обо всей топологии и для каждого шарда отмечать инстансу микросервиса что шард «занят». Отдельно балансировщика тут не нужно, но внешняя система, например consul/etc/zookeeper может использоваться для такой задачи.
Кэш данных? Не совсем понятно для чего он, неужели сетевые задержки настолько большие и критичные?
Кэш данных, да. Сетевые задержки критичны до безобразия. Нужно вот чтоб как будто бы 10 отдельных независимых сервисов с возможностью держать данные в кеше и выдавать их прям из памяти
А, в такой конфигурации можно по-другому. Перед базой поставить микросервисы-кеши. Если пришёл запрос на микросервис - смотрим в кеш и если нет - идём в базу. А вот ходить к микросервисам уже нужно знать о топологии. и делать какой-нибудь instance = hash(requestId) % instance_count. Главное кейс с переложем и вылетом ответственного за микросервис шарда разрешить (можно в сторону rendezvous hashing глянуть). А есть ли возможность поставить lru кеш перед монгой и забить на шарды вообще?
должно быть минимум сетевых взаимодействий и прослоек, желательно чтобы любой запрос сразу из памяти получал ответ
Если задержки критичны, то вы можете выкинуть монгу и запихнуть все данные в ваш сервис, in-memory. И обернуть все это сервис-мешем, где по ключу будет роутинг на нужный инстанс.
персистить асинхронно в фоновом режиме?
Тоже вариант но в случае отказа сервиса время восстановления будет неприемлемо большим, в зависимости от объемов само собой
Реплики. Не надо держать 1 инстанс шарда
И тут вступает проблема их синхронизации, которую довольно сложно решать с нуля
Тут вопрос как заливать данные. Чем вы готовы пожертвовать.
Нетворк хопы все не загубят?
Смотря в чём дело, я так думаю в throughput - обычно базе просто не хватает ресурсов выполнить все запросы. Поэтому можно пожертовать хопом для решения задачи.
Обсуждают сегодня