Comments 8
А использовался настоящий Redis или Redis-содержащий продукт? Например dragonfly или garnet?
Верно ли я понял, что сейчас у вас на каждом поде полная inmemory копия всей базы данных?
Какого размера сейчас эти кеши (например, в Мб) и что вы планируете делать, когда данные перестанут помещаться в память одного пода?
Я понял, что ответ на первый вопрос - да, все данные умещаются на одной реплике в памяти.
Если не будет хватать, то вижу единственный вариант при такой архитектуре - шардирование reader-ов. И новый компонент gateway на входе трафика.
Есть ещё варианты?
В статье речь о том, что вертикальное масштабирование - не выход, но предложенное решение принципиально не отличается от репликации того же редиса, который был забракован.
Интересное начинается когда нужно шардировать данные и в рантайме добавлять новые шарды, не увеличивая РТ сервиса и выдерживая slo по времени и гарантиям доставки обновлений в базу. Про тонкости практической реализации этой механики я бы почитал с удовольствием.
Чето как-то вообще не наглядно
...Представьте, что вы бьёте по базе данных или даже по инстансу Redis с частотой 1 миллион запросов в секунду (10^6 Req/s). Без серьёзных вложений это нежизнеспособно... традиционное вертикальное масштабирование (наращивание мощностей DB/Redis серверов) очень быстро превращается в крайне дорогую затею...
Очень странно про "традиционное вертикальное масштабирование" относительно redis, когда у него есть для read-нагрузки репликация, а для r/w кластерный режим. Да, один инстанс редис 1 MRPC на чтение не вывезет (https://habr.com/ru/articles/849264/) - поставь пяток (а не 20) RO реплик и проблема решена "из коробки".
А что за данные такие, которые не надо например чем-то обогащать. Это какой-то внутренний микросервис?
Больше 1 млн запросов в секунду на Go: уроки продакшена