Статья была выбрана Github, добро пожаловать в Star:github.com/yehongzhi

предисловие

В настоящее время Redis является наиболее широко используемым кешем, и я думаю, что все с ним знакомы. Однако с использованием кеша не все так просто.Также необходимо учитывать проблемы лавины кеша, поломки кеша и проникновения в кеш.Что такое лавинный кеш, пробой и проникновение в кеш?Как решить эти проблемы?Об этом далее.

Кэш Лавина

Что такое кэш-лавина?

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

анализировать:

Ключом к возникновению лавины кеша является одновременная массовая недействительность ключа. Почему возникает эта проблема? Существует несколько возможностей. Первая возможность заключается в том, что Redis не работает, а вторая возможность — в том, что используется одно и то же время истечения срока действия. После выяснения причины, какое решение?

решение:

1. Добавьте случайное значение к исходному времени отказа, например 1–5 минут случайным образом. Это позволяет избежать лавины кеша, вызванной использованием одного и того же срока действия.

Если происходит лавина кеша, есть ли какая-то итоговая мера?

2. Используйте предохранительный механизм. Когда трафик достигает определенного порога, он напрямую возвращает запрос, такой как «перегрузка системы», чтобы предотвратить попадание слишком большого количества запросов в базу данных. По крайней мере, некоторые пользователи могут гарантированно использовать его в обычном режиме, а другие пользователи могут получить результаты после нескольких обновлений.

3. Чтобы улучшить возможности аварийного восстановления базы данных, можно использовать стратегию подтаблиц подбазы данных и разделения чтения и записи.

4. Чтобы предотвратить лавину кеша, вызванную простоем Redis, можно создать кластер Redis для повышения устойчивости Redis к сбоям.

разбивка кеша

Что такое разбивка кеша?

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

анализировать:

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

решение:

1. Как упоминалось выше, если бизнес позволяет, для ключа точки доступа можно установить бессрочный ключ.

2. Используйте взаимоисключающие блокировки. Если кеш недействителен, к базе данных можно обращаться только после получения блокировки, что уменьшает количество запросов, одновременно попадающих в базу данных, и предотвращает уничтожение базы данных. Конечно, это приведет к снижению производительности системы.

проникновение в кеш

Что такое проникновение в кеш?

В большинстве случаев, когда мы используем Redis, мы используем ключ для запроса соответствующего значения.Если ключ, отправленный в отправленном запросе, не существует в Redis, то кеш не будет найден, а если кеш не может быть найден, база данных будет запрошен. Если таких запросов большое количество, то эти запросы напрямую попадают в базу данных, как будто они «проникли» в кеш, это явление называется проникновением в кеш.

анализировать:

Суть в том, что значение ключа нельзя найти в Redis, что принципиально отличается от разбивки кеша.В случае проникновения в кеш входящий ключ не существует в Redis..假如有黑客传进大量的不存在的key，那么大量的请求打在数据库上是很致命的问题，所以在日常开发中要对参数做好校验，一些非法的参数，不可能存在的key就直接返回错误提示，要对调用方保持这种“不信任”的心态。

решение:

1,Сохранить неверный ключ в Redis. Если Redis не может найти данные, и база данных не может их найти, мы сохраняем значение ключа в Redis, устанавливаем value="null", и в следующий раз, когда вы будете запрашивать через этот ключ, вам не нужно запрашивать базу данных снова. Этот метод обработки определенно проблематичен: если несуществующее значение Key передается каждый раз случайно, хранить его в Redis бессмысленно.

2,Используйте фильтр Блума. Функция фильтра Блума заключается в том, что если ключа не существует, то его и не должно быть, если он говорит, что ключ существует, то он, скорее всего, существует (есть определенный процент ложных срабатываний). Таким образом, мы можем добавить слой фильтра Блума перед кешем.При запросе перейти к фильтру Блума, чтобы проверить, существует ли ключ, и вернуть его напрямую, если он не существует.

Суммировать

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

Итак, эта статья здесь, спасибо за чтение, я надеюсь, что вы сможете что-то получить после ее прочтения.

Ставьте лайки, если считаете это полезным, ваши лайки — самая большая мотивация для моего творчества.~

Я программист, который изо всех сил старается запомниться. Увидимся в следующий раз! ! !

Возможности ограничены, если есть какие-то ошибки или неуместности, пожалуйста, критикуйте и исправьте их, учитесь и общайтесь вместе!