Есть основное приложение на Loopback. В приложении есть примерно 25-30 моделей о изменениях в которых на клиентах узнают через стримы (EventSource). Есть одна существенная проблема, у юзеров подписаных на стримы могут быть разные условия для получения апдейтов. То есть, после обновления модели, нужно достать с базы самого юзера, его компании и координаты (это все пример). При небольших нагрузках все работает нормально, но примерно после 1000 подключенных юзеров начинают появлятся задержки, оно и понятно, так как в один и тот же момент проверяются условия для 1000 юзеров, и практически в каждой проверке есть запросы к базе. Для оптимизации всего этого чуда, планирую создать отдельный микро-сервис который будет обрбатывать информацию, это должно понизить нагрузку на основное приложение. С этим думаю проблем не должно возникнуть. Второе что планирую внедрить, это максимально все кешировать что бы сократить нагрузку на базу. А вот с этим уже есть проблемы. Как правильно (оптимально) делать кеш, юзать для этого Redis или хранить все в памяти самого приложения, с учетом того что сохранность этого кеша для меня не важна, то не знаю или умесно юзать что то постороннее. Если все же юзать Redis, то для него нужно выделять отдельную мвшину или поднимать рядом с приложение? И последнее, и самое не ясное для меня, в один и тот же момент в базу может стрельнуть несколько одинаковых запросов. Допустим их будет 10, а нужно сделать что бы только 1 в базу, а остальные с кеша, как такое провернуть?
ты не можешь кэшировать работу логики приложения -> тк ты сталкнешся с тем что кэш не соответствует реальной модели данных, и это приводит к ошибкам в сервисе (погугли инвалидация кэша), в итоге чтоб тебе держать кэш корректным тебе нужно будет еще больше нагрузки проводить и сверять корректность кэша с данными в БД.
так что про кэширование логики забудь, кэширую простые готовые ответы пользователю, не поболее того.
1. Для гиганского ускорения (в тысячи раз) тебе нужно перенести модель и логику в оперативную память, а для этого забыть про всякие там ноды хуеды, а перейти на статически типизированные компилированные языки, и уже эту модель данных в памяти асинхронно сохранять в базу данных, тогда все летать будет.
2. Для легкой и самое главное корректной разработки сервиса с большим количеством "событийных" зависимостей - желательно использовать "Функциональное реактивное программирование" (в гугле поищешь материалы почему и как это реализуется)
Выделить подписку в отдельную сущность: она должна держать список подписанных пользователей на данное событие, при этом сделать синхронный кэш в памяти (ну или просто кэш) - т.е. вот пользователь подписывается на событие икс в категории игрек - записываем это в профиль юзера и добавляем юзера в список подписок категории "игрек.событие" . Как только событие происходит - нам не надо проходить по всем профилям пользователей, а достаточно просто пройтись по всем подписанным пользователям. Либо, можно оптимизировать работу с БД и переложить на её плечи проверку "подписан ли пользователь икс на подписку игрек". Как именно делать оптимальнее - зависит от многих факторов: самый простой вариант - это в памяти приложения, редис же имеет смысл для кластеризации и распределения нагрузок - но это может несколько увеличить время обработки запроса.
Средний
Средний
Простой
