Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Идея с VoidCache подозрительная. Если у вас нет кеша в реальности, то у вас нет и проблемы устаревания кеша, вам не требуется инвалидация, вы не получите на проде неактуальных данных. Т.е. в момент когда вы решите подключить кеш, внезапно пойдут проблемы. Может хотя бы кеш в оперативке сделать, с управляемым временем жизни и то будет польза?
Тогда это не VoidCache некий, а любой другой класс который отвечает за соединение с внешним сервисом\СУБД - репозиторий, сервис, менеджер, на любой вкус.
И их реализация в любом случае хорошая практика, вне зависимости от теоретического использования кешей.
Добавлю, что у разработчиков бывает представление о кэше как о штуке, которая решит проблемы с производительностью плохо спроектированного приложения. Представление меняется заменой слова на "базу данных", чем по сути кэш и является.
согласен кэш не является спасением от плохой архитектуры, а лишь инструментом оптимизации, в дополнение к уже хорошо спроектированной системе. + упомянул что не всегда его использование дает профит
Кэши имеют разные реализации и используются далеко не только в вебе. Банальный пример геймдев, где кэш либо хранится в хэш таблицах либо интегрирован прямо в код функции например. У кэша нет такой сложной архитектуры, как у БД, даже у noSQL.
Да и подходы разные. Например, кэш подразумевает полное удаление себя, без каких либо последствий для сервиса или проекта. Полное удаление всех данных в бд думаю понятно, какие последствия будет иметь.
А заморозка применяется в таких кэшах, как в процессорах?
О какой "заморозке" в процессорных кэшах идёт речь?
И да программный кэш очень сильно отличается от процессорного по внутренней архитектуре и основным сложностям.
В некоторых процессорах есть команда freeze кэш страницы. Не помню деталей, да и не использовал ни разу
Поскольку кэш работает на уровне кэшлайнов, а не страниц, то "фриз кэш страниицы" - звучит как какая-то ерунда.
Вам наверное на уровне идеи лучше объяснить какое поведение вы подразумеваете.
По моему там употреблялось page, а не line, но не уверен. И смысл был в том, чтобы считать массив констант из динамической памяти, потом заморозить этот лайн или пейдж, пройти цикл обработки с их использованием, заморозить кэш инструкций с этой функцией, а потом заниматься чем то другим, чтобы при появлении новых данных это всё повторялось уже из кэша
Честно говоря супер пространное описание.
Смутно похоже на 1 из 3 вещей:
- Tight Coupled Memory (программно управляемый кэш)
- LL SC синхронизацию
- watch points
В целом неясно в чём смысл: оставить надолго некоторые данные в кэше или же "разбудить" ожидающий процесс? Если цель "разбудеть" - то обычно так не делают скрыто в аппаратуре, а посылают уснувшему процессу явный сигнал на уровне программной модели.
В общем случае в микроэлектронике - сложность сделать доступ к памяти быстрой. А в программном кэше сложность - вовремя инвалидировать устаревшие данные (т.к. данные мимо кэша идут в виде "запросов" по которым надо угадать что может инвалидироваться).
Вот вокруг этого: сложности инвалидации (а ещё и "когерентности", если она есть) - построена основная архитектура программных кэшей.
Да, по бенефитам похоже на TCM ARMа но вряд ли. Видел лет 30 или больше назад в сигнальных процессорах TI, а может и ещё где, когда переставали делать статическую память, а динамическая существенно тормозила. Внутренняя память процессора могла работать как статическая, а могла как кэш. И вот в режиме кэша можно было принудительно загнать туда константы и куски кода, которые должны были выполняться постоянно и гарантированно быстро, а свободную часть оставить для кэширования медленной внешней памяти
Понял. Ну из общих соображений:
1. Вам можно забить на согласованность (*) - просто кладёте эти данные в отдельный кэшик и забываете
2. Вам нельзя забивать на согласованность - данные иногда будут инвалидироваться => подолгу будут недоступны. Лучшее что вы можете сделать это повысить приоритет данных при вытеснении (такая возможность наверняка должна быть).
*) В терминах CAP-теоремы
Джонни Кэш ещё. Из категории, которая тоже много на что влияет в нашей жизни.
спасибо за фидбэк. рад если информация оказалась полезной, но это лишь начало. советую углубиться в упомянутые advanced алгоритмы (не зубрить их устройство, а просто почитать для расширения кругозора и возможно попробовать реализовать какой нибудь на практике). + в дополнение почитайте про методы инвалидации и возможные проблемы (e.g thundering herd problem)
Интересная статья. Только вливаюсь в программирование, поэтому эта информация очень к стати
А почему "внутренний кэш" мешает горизонтальному масштабированию, а внешний - "легко горизонтально масштабируется"? Это совершенно не верно, тип кэша никак не связан с простотой масштабирования. Более того, все приведенные примеры для внешних кэшей (Тарантул, Редис) не масштабируются горизонтально. А вот вполне себе внутренний Хазелкаст - как раз масштабируется.
И подобных неточностей в статье довольно много, кажется, что автор не очень хорошо понимает, как и для чего нужно кэширование и просто пересказывает википедию. Для студента или стажера - достаточно. Для миддла - уже категорически недостаточно информации и понимания. К сожалению, в статье нигде не указано, что она для студентов.
Redis Cluster вроде горизонтально масштабируется, а внутренний - это думать надо как все сделать!
джунам пойдет, а по факту - бери, что попроще и не выдумывай.
На сколько внешний медленнее внутреннего? Никто не переживает, вот и берут, то попроще.
В теории - да, в Redis Cluster есть шардинг. Но в реальном использовании там все не так просто и масштабирование нужно делать очень аккуратно, при этом еще и справляясь с кучей ограничений кластера. Внутренний на хазелкасте - масштабируется примерно так же, чуть сложнее для программиста, чуть проще для админа, разница не принципиальна.
Но, в любом случае, горизонтальное масштабирование не зависит от того, внутренний или внешний кэш.
Медианный latency внутреннего кэша примерно на два-четыре десятичных порядка меньше, чем доступ через сеть, хотя реальные значения зависят от множества параметров (как ни странно, нигде не увидел актуальных данных по latency доступа к современной серверной памяти и сетевых задержек внутри современного ДЦ).
На надо помнить, что для сети какой-нибудь 99.99 персентиль будет много выше медианы и может легко доходить до десятков ms, а время доступа к локальной памяти гораздо меньше подвержено флуктуациям.
Очень интересно. Сложный материал легким языком. Огонь! А Jitter это из этой серии?
Интересно было почитать. Получается хранения ссылок в переменных, тоже кеширование? Если мы храним данные сразу вместо того каждый раз их искать где-то непонятно где и получаем возможность сразу перейти по адресу, а не искать его каждый раз.
Только вливаюсь в программирование и пока не совсем понятно зачем мне это было нужно, но стало интересно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кэш. Теория кэширования. Устройство и разновидности кэша