Накопление знаний
Математическо-низкоуровневое

Лето, Солнце, Тепло - Кеширование

Собственно ключевая ссылка на сегодня это https://varnish-cache.org/extras/index.html
Уйдет примерно пару суток чтобы попробовать изучить расширения "Варниша" - я же сегодня долго размышлял про логику уровня приложения, и свои наработки по кешированию.
Точнее не наработки....

Микросервис и монолит


Когда микросервис ОЧЕНЬ хорошо делает свою работу, он рано или поздно становится монолитным сервисом требующем кластеризации и работу над отказоуйстойчивостью, и кстати следующим этапом будет монетизация. Обычно это называется попасть в рынок.

Но когда мы делаем приложение которое требует непрерывной работы пользователей (на 1С или не на 1С - неважно), нам не до микросервисов.
Мы всего лишь пишем данные которые вводит пользователь, запускаем расчеты и выдаём пресловутое 42

И если гипотетически предположить, что мы наконец-то окучили всех пользователей и нам выдалось времячко побороться за TTFB (time to first byte) - первое что Вам предложат для кеширования и ваще для быстроты ответа - это Nginx.
Если вдруг у вас окажется право развертывать инфраструктурные сервисы, вы возможно поставите CaddyServer и не будете извращаться с конфигами Nginx. Но поверьте - для правильного кеширования и этого мало.

Обратный ход исследования


Тут нам пригодится подход "обратного исследователя" - а именно. Возьмем сервис CloudFlare - я думаю все в курсе, что они такие же программисты/менеджеры как и все. Поэтому у них должен стоять какой-то софт. И соответственно - подобный софт просто обязан быть представлен в OpenSource сегменте. Собственно ссылка была в самом начале - основной пример это "Варниш", плюс огромная куча примеров на GoLang/Rust

Но все эти сервисы за последние 10 лет никак в целом не решают конечныч задач. Они все и Варниш, и ЭнДженикс и даже Кэдди продолжают быть сервисами инфраструктурщиков, которые еще дальше от пользователей чем программисты.

Рождая первичные зарисовки


При рассмотрении проблематики кеширования, мы должны мыслить от потребляемой сущности - она в общем случае

  • получается пользователем методом GET
  • записывается в БД методом INSERT
2 первичных вопроса

  • кто будет отдавать "кешированное значение" пользователю, находясь максимально близко к нему
  • кто будет принимать "записывающие" запросы, чтобы сохранить значение в СУБД

И что будет посередине.

Добавляем определённости


Наши знания про событийность уже показывают нам что кеш, должен быть подписан на изменение значения сущности, так как "вставка происходит" не там где он (кеширующий сервис) - уже на этом этапе возникают

  • стриминговые сервисы
  • протоколы AMQP

Но что мы должн кешировать ? Откуда мы узнаем TTL (время жизни значения) - не эмпирикой жеж ? А что если сервис рухнет ? Отказоустйчивые кластера всегда отказывают - CloudFlare DNS третьего дня прилег так, что многим поплохело.

Еще вопросы


Если хватит сил исследовать дальше - то вопросы будут "шириться"

  • Как прогревать кеш первый раз и после падения (pg_prewarm слово для гугления аналогий) ?
  • Что делать с кеширование результатов полнотекстового поиска ?
  • Что делать если клиент работает по бинарному протоколу типа GRPC или 1C-ного ZIM-SOME-XML ?
  • Что делать с любителями включать кеширование СУБД и больше не заморачиваться ?
  • Где взять "правила" кеширования? Особливо, когда нужно делать ACL - то есть еще и разграничивать доступ уже на этапе доступа к кешу.

От кнопки


В итоге - кеширование как инфраструктурный сервис на сегодняшний день вообще не является проблемой и просто требует грамотного инфраструктурщика.
Ошибкой архитектора в данном случае является попытка изначально спроектировать только техническую составляющую, хотя в итоге большая часть затрат опять лежит в плоскости бизнес-вопросов. Поэтому совет начинающим архитекторам простой: при упоминании кеширования начинайте с бизнес-вопросов:

  • Если цена меняется каждую секунду - сколько времени я могу показывать цену отдельному клиенту, до того как необходимо показать обновленную цену.
  • Если средний чек изменяется 10 раз в минуту, какую цифру показывать генеральному на его мобильнике если он тыкает кнопку "Обновить" каждую секунду ?

Чтобы вы понимали - даже OData/Rest можно накрыть кеширующим прокси, чтобы разгрузить БД - вопрос только в том какие правила мы заложим для времени хранения. Начинайте с этого - остальное можно по API реализовать хоть из 1С, хоть из PHP.


на заглавной картинке результаты работы с "преднагревом СУБД" от EnterpriseDB https://www.enterprisedb.com/blog/autoprewarm-new-functionality-pgprewarm