1. В чем проблема проникновения в кеш?
Как показано на рисунке, обычный запрос обычно проходит через уровень кэша, а затем на уровень хранения.
И поскольку данные не могут быть получены в хранилище, данные не помещаются в кеш, в результате чего большое количество запросов достигает уровня хранилища, что является определением проникновения в кеш.
Одной из функций кеша является защита хранилища, которым является база данных, такая как MySQL, и если кеш проникнет, этот уровень защиты будет потерян.
2. Что вызывает проникновение в кеш?
- Проблема самого бизнес-кода: я сталкивался с кодом, написанным кем-то ранее, и обнаружил, что данные есть, но при сохранении в кеше использовалась пустая переменная. Это относительно низкоуровневая, но бывает и такая ситуация
- Вредоносные атаки, поисковые роботы и т. д.: например, для интерфейса GET, если злоумышленник будет продолжать передавать некоторые ненормальные значения в параметрах, это приведет к сбою кэширования большого количества запросов, что неизбежно приведет к кэшированию проникновение, а объем данных достаточно велик Это также приведет к зависанию хранилища в случае
3. Как обнаружить проникновение в кеш?
- Время отклика бизнеса: мы можем использовать ELK или другие системы мониторинга для обнаружения бизнес-интерфейсов. Изначально кеш имеет относительно быстрое время отклика, если порог часто превышается, то это обязательно отразится.
- деловая проблема
- Связанные индикаторы: общее количество вызовов, попаданий на уровне кэша, попаданий на уровне хранилища.
4. Как решить проблему проникновения в кеш?
- Кэшировать пустые объекты: если хранилище действительно пустое, мы также можем кэшировать пустой объект и установить время истечения срока действия, например 5 или 8 минут, в зависимости от конкретного сценария использования. Хотя это правда, что хранилище пустое, это может уменьшить нагрузку на хранилище для нас и избежать некоторых опасностей проникновения в кеш.
Потенциальная проблема:
- Нужно больше ключей: Как и в случае с вредоносной атакой, о которой мы упоминали ранее, если ключи каждого запроса разные, то эти ключи будут записаны в кеш, хотя это всего лишь нулевое значение, но если объем данных велик, он будет все еще будут некоторые эффекты, поэтому мы обычно используем время истечения срока действия, чтобы уменьшить такие риски.
- Будут «краткосрочные» несоответствия между уровнем кэша и уровнем хранения: поскольку уровень кэша устанавливает время истечения срока действия, если уровень хранения является интерфейсом, после того, как ключ, сохраненный в уровне кэша, становится нулевым, данные этого key добавляется на уровень хранения, он будет возвращать null только в течение короткого периода времени.
- Фильтр Блума: поместите все возможные ключи в достаточно большое растровое изображение, и несуществующие ключи будут перехвачены этим растровым изображением, что позволит избежать давления запросов на базовую систему хранения, таких как номера телефонов и т. д.
больше хороших статей
Пожалуйста, отсканируйте QR-код ниже
Добро пожаловать, чтобы обратить внимание~