Pull to refresh

Comments 16

Человек просто упомянул, что пишет на го, а затем предложил рассказать о БАЗОВЫХ концепциях (не зависящих от языка).

Вы статью читали? Есть отсылка на структуру map в языке и библиотеку singleflight.

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

  • кэш браузера

  • кэш прокси-сервера

  • кэш на входе в сайт

  • кэш движка сайта

  • кэш приложения

  • кэш движка БД

  • кэш ОС/дисковой системы, где лежит БД

То есть кэши могут складываться в цепочки, а то и в деревья (сайт может обращаться к другим API/сайтам на том же сервере или на других серверах).

И последние 5 уровней кэша могут содержать одинаковые данные ;)

А на остальных уровнях данные не одинаковые, не валидные что ли? :-O

Другие уровни не на той машине, у юзера, например. Я имел ввиду то, что одна машина может хранить в сврей оперативке одно и то же несколько раз.

И все равно не будут.
Данные в кеше ОС отличаются от данных, используемых БД для выполнения запроса: они содержат метаданные, могут быть сжаты, etc.
Не все прочитанные данные вообще попадут в дисковый кэш или останутся в нем к моменту окончания запроса.
В разделяемой памяти планировщик БД оставит не все данные, которые понадобились для выполнения запроса.
Размер ответа, обычно, существенно меньше размера данных для его (запроса) выполнения.
И далее данные продолжат преобразовываться, пока, наконец, не отправятся наружу.

Полезный комментарий. Он же не говорит, что нужно всегда создавать несколько уровней кэша. Просто полезно знать, что в практике есть такие системы.

А почему это у Вас кэш всегда за приложением находится?

Как выше упомянули, кешировать можно еще до приложения. Ну хотя бы в том же Nginx. Особенно статику и пр. Ну и вопрос CDN не затронут.

Стоит добавить про проблемы кеширования в мапах, когда несколько инстансов приложения. Возникает задача синхронизации кеша, чтобы было консистеньненько.

Одна буква "т" всё-таки потерялась. Непростое слово, согласен.

Оно может сохранить данные в кэш сразу после обращения к БД, а может предварительно сделать еще ряд манипуляций с данными и только затем сохранить их в БД

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

Спасибо за статью. Для новичков очень познавательно. Статья даёт базу для самостоятельного изучения вопроса.

Sign up to leave a comment.

Articles