Использование кэша Redis значительно повышает производительность и эффективность приложений, особенно для запросов данных. Но одновременно это приносит и некоторые проблемы. Среди них самой важной проблемой является согласованность данных, которая строго неразрешима. Если требуется согласованность данных, кэширование нельзя.
Другие типичные проблемы — проникновение в кэш, лавина кэша и его сбой. В настоящее время в отрасли существуют более популярные решения. Эта статья не направлена на более совершенное решение этих трёх проблем и не для того, чтобы подорвать популярные решения в отрасли. Вместо этого мы продемонстрируем эти три проблемных явления на основе непосредственной операции кода. Причина в том, что сложно иметь в голове яркое представление, просто глядя на академическое объяснение этих задач, а с помощью реальных демонстраций кода можно углубить своё понимание и понимание этих задач.
Проникновение в кэш
Проникновение в кэш означает запрос данных, которых нет в базе данных. Если ключа нет или он истёк, база данных запрашивается, и объекты помещаются в кэш. Если объект запроса к базе данных пуст, он не кэшируется.
Поток кода
- параметр передаёт первичный идентификатор ключа объекта
- Получите объект из кэша на основе ключа
- Если объект не пуст, он возвращается напрямую
- Если объект пуст, выполните запрос к базе данных
- Если объект, запрошенный из базы данных, не пуст, поместите его в кэш (установите время истечения). Представьте себе такую ситуацию: что произойдёт, если переданный параметр будет -1? Это -1 — объект, который не должен существовать. База данных будет запрашиваться каждый раз, и каждый запрос будет пустым, и не кэшируется каждый раз. Если происходит вредоносная атака, эта уязвимость может быть использована для давления на базу данных или даже для её перегрузки. Даже если используется UUID, легко найти несуществующий КЛЮЧ и атаковать.
В своей работе я использую метод кэширования нулевых значений, то есть шаг 5 в процессе [кода]: если объект, запрошенный из базы данных, пуст, он также помещается в кэш, но время истечения установленного кэша короткое, например, установка на 60 секунд.
Лавина кэша
Cache avalanche означает истечение срока действия кэш-набора за определённый период времени.
Одна из причин лавины, например, при написании этой статьи — скоро наступит 0 часов двенадцатого дня, и вскоре начнётся волна поспешных покупок. А потом в час ночи истекает запас этой партии товаров. Запрос доступа к этой партии товаров падает на базу данных, и для базы данных периодически возникают пики давления.
Когда Сяобиан занимается проектами в сфере электронной коммерции, он обычно использует разные категории товаров и хранит разные циклы. Товары из той же категории, плюс случайный фактор. Таким образом, срок годности кэша можно максимально распределить, а время хранения продуктов в популярных категориях будет дольше, а время кэширования продуктов в непопулярных категориях — короче, что также может сэкономить ресурсы кэширующего сервиса.
На самом деле, централизованное истечение срока действия не является фатальным явлением, и более смертоносная лавина кэша заключается в том, что узел сервера кэша выходит из строя или отключается. Поскольку естественная лавина кэша должна быть создана за определённый промежуток времени, база данных выдерживает давление, и в этот момент она также способна выдержать давление. Это не более чем периодическое давление на базу данных. Простой узла сервиса кэша создаёт непредсказуемое давление на сервер базы данных и, скорее всего, мгновенно перегрузит базу данных.
Разбивка кэша
Кэш-сбой — это ключ, который очень горячий, постоянно несёт большую параллельность, большая параллелность сосредоточена на доступе к этой точке; когда ключ выходит из строя, непрерывная большая параллельность прорывается сквозь кэш и напрямую запрашивает базу данных, подобно тому, как сверлить отверстие в барьере.
Когда Сяобиан занимался проектами в сфере электронной коммерции, он сделал этот продукт «хитом».
На самом деле, в большинстве случаев такой взрыв сложно оказать мощное давление на сервер базы данных. Мало кто из компаний достиг такого уровня. Поэтому прагматичный редактор готовится к основным продуктам заранее, чтобы кэш никогда не истек. Даже если некоторые продукты ферментируются до попаданий, их можно установить как никогда не истекающие сроки годности.
Основной путь прост, и замок mutex-ключа для взаимного отклонения практически не используется.
|
Опубликовано 19.11.2019 9:55:04
|
|
|
|
