Comments 5
Я не очень хочу критиковать решение, так как не в курсе всех нюансов и требований, но вот это место выглядит стремно для большинства задача
В результате нагрузка на сервис по RPS та же, что и раньше, но до хранилища доходит от силы половина. Остальное возвращается клиенту в виде 429 ответа.
Простой пример. Где-то там выше над нами веб-клиент и серверное приложение. Допустим для получения "удовлетворения" нам надо отработать 10 запросов. К примеру развесистая start page. Допустим мы попали в ситуацию, когда конкуретных запросов стало больше чем надо, и некоторые пошли "в сад". Пусть это будет половина. Тогда понятно, что почти никто не будет "удовлетворен", так как кто-то получил 8 из 10, кто-то - 7, кто-то вообще 2. Плохо
Если нам это не важно - я бы просто ставил очередь. Все пришли, дале FIFO, но строго ограниченным числом потоков. Можно прикрутить autoscaling на основе метрик базы, если хочется применить формулы. Возможно будет медленнее, зато прозрачно и легко мониторить.
Если клиенты таки хотят получать ответы на много вопросов, вопрос можно решить агрегацией сообщений, чтобы в работу брался полный пакет "счастья". Тогда нет проблем с частичным "удовлетворением", да и сборка/разборка сообщений в пакет на "месседжинге" делается относительно несложно
Это все не критика, а просто рассуждения на схожую тему
Простой пример
Тут ведь очень зависит от множества нюансов - куда эти 10 запросов идут (в одну ли базу), сколько из них можно просто из кеша возвращать и пр. Если мы все 10 перенаправляем в одну базу, без кешей - да, описанным тут такую проблему лечить не выйдет. В любом случае, троттлинг обычно - это когда стало плохо, и ты не хочешь, чтобы оно превратилось в "ужасно". Если мы уже пришли к тому, что база начинает сильно тормозить - пускай что-то отбрасывает, если ей это поможет не помереть, пока разбираемся с проблемой.
FIFO, но строго ограниченным числом потоков
В принципе, это конкарренси лимит и есть, только не на уровне сервиса, а чуть выше. Автоскейлинг сервиса на основе метрик базы, в которую он ходит (если я правильно понял) - по мне звучит страшновато. Там и скорость скейлинга (можем пропустить слишком много и очень долго), и зависимость деплоя одной сущности от другой, и еще несколько нюансов не нравятся. По мне тут и с прозрачностью, и с мониторингом грустнее выходит.
Тут ведь очень зависит от множества нюансов - куда эти 10 запросов идут (в одну ли базу), сколько из них можно просто из кеша возвращать и пр.
Я исходил из вашего примера, насколкьо я его внимательно изучил :) Очередь иммет смысл перед уже "исполнителем", так как она по сути меняет "загрузку" по сессиям на время ожидания естественным образом. тут достаточно сходить в магаз :)
Отбрасывание кстати тоже может реализовываться в очереди, так как большинство реализаций имеют банальную фичу, как время жизни сообщения в очереди. Т.е. если сообщение уже живет больше 5 секунд - можно считать, что оно уже не нужно и его можно удалять
Если мы уже пришли к тому, что база начинает сильно тормозить - пускай что-то отбрасывает, если ей это поможет не помереть, пока разбираемся с проблемой.
Это да, наша основная задача - обеспечить загрузку баз полезными запросами. Т.е. любой запрос должен быть не просто обработан, но и вовремя, чтобы пользователь его дождался.
Для меня всегда было сложнее выполнить вторую часть. Просто отрезать несложно, но вот сделать это консистентно и вовремя - это сложнее.
Поэтому хочется в сложных кейсах иметь запросы в виде некоего знания, которым можно управлять, чтобы обеспечить консистентность выполнения. Т.е. если я взял в работу запрос из 10 подзапросов, тогда надо все 10 пропихнуть, иначе если я пропихну только 8 - все будет зря и самое обидное - ресурсы то потрачены :(
Автоскейлинг сервиса на основе метрик базы, в которую он ходит (если я правильно понял) - по мне звучит страшновато
Обычно можно в параметрах очереди указать, в сколько потоков из нее можно читать. Поэтому не надо ничего поднимать, достаточно менять параметр. К примеру, запустили сразу 100 обработчиков (цена вопроса - только операцтивная память), а на очереди - 20 потоков. Итого, в один момент времени 20 работают (если конечно есть работа), а 80 ждут.
По мне тут и с прозрачностью, и с мониторингом грустнее выходит.
Если на очередях все - то мониторя длину очереди и время жизни сообщений там вы сразу видите всю картину. Это просто условно очевидно, тот же пример супермаркета. Как только очереди достигли условно какой-то точки - надо открывать новую касу.
Не совсем понятно что плохого в репликации, это ведь ещё и дефолтная вещь для отказоустойчивости. Данное решение кажется очень сложным.
Без денег, репликации и кеша: ограничиваем нагрузку на сервисы, используя подходы из TCP