- jordan обувь для продажи
- 16370
|
Использование кэширования Redis значительно повысило производительность и эффективность приложений, особенно для запросов к данным. Однако в то же время оно порождает и некоторые проблемы. Одна из наиболее острых проблем - проблема согласованности данных - неразрешима в строгом смысле слова. Если существует высокое требование к согласованности данных, то кэширование не может быть использовано.
Другие типичные проблемы - проникновение в кэш, лавина кэша и разрушение кэша. В настоящее время в отрасли существуют более популярные решения для всех этих проблем. Данный пост не претендует на идеальное решение этих трех проблем, а также не направлен на подрыв популярных в отрасли решений. Скорее, это демонстрация этих трех явлений на примере реальных операций с кодом. Причина в том, что, если посмотреть на академическое объяснение этих проблем, то в голове сложно составить представление о концепции, а с демонстрацией реального кода вы сможете углубить понимание этих проблем и знания.
Проникновение в кэш
Под проникновением в кэш понимается запрос к базе данных для получения данных, которые не должны существовать. При обычном использовании кэша процесс выглядит примерно так: при запросе данных сначала выполняется запрос к кэшу, если ключ не существует или срок действия ключа истек, а затем выполняется запрос к базе данных, и запрос к объекту, помещенному в кэш. Если объект запроса к базе данных пуст, он не помещается в кэш.
Поток кода
- Параметр, переданный в ID первичного ключа объекта Получить объект из кэша на основе ключа Если объект не null, вернуть его напрямую Если объект null, выполнить запрос к базе данных Если объект, запрошенный из базы данных, не null, поместить его в кэш (установить время истечения) Представьте себе такой сценарий, если параметр, переданный в -1, что будет в этом случае? Этот -1 - объект, который не должен существовать. Он будет запрашивать базу данных каждый раз, и каждый раз запрос будет пустым, и каждый раз он не будет кэширован. Если есть вредоносная атака, она может воспользоваться этой уязвимостью и оказать давление на базу данных, или даже перегрузить ее. Даже с UUID легко найти несуществующий KEY и атаковать.
В своей работе я буду использовать кэш пустых значений, то есть [поток кода] на шаге 5, если объект из базы данных запрошен пустым, также помещается в кэш, просто установите время истечения кэша короче, например, установите 60 секунд.
Лавина кэша
Лавина кэша - это когда кэш централизованно истекает и становится недействительным в определенное время.
Одна из причин лавины, например, во время написания этой статьи, скоро будет двойная двенадцать ноль-ноль, скоро принесет волну спешки, эта волна товаров время более сосредоточены в кэш, предполагая, что кэш в течение часа. Затем в час ночи кэш этой партии товаров истекает. И запрос доступа к этой партии товаров, все попадают в базу данных, для базы данных, там будет периодическая волна давления.
Когда я занимаюсь проектами электронной коммерции, я обычно беру разные категории товаров, кэш которых имеет разные циклы. Товары в одной классификации, плюс случайный фактор. Это позволяет максимально распределить время истечения кэша, и, увеличивая время кэширования для товаров в популярных категориях и сокращая время кэширования для товаров в холодных категориях, можно также сэкономить ресурсы кэш-сервиса.
На самом деле, централизованное истечение, но не очень фатальное, более фатальной лавиной кэша, является кэш-сервер узла вниз или отключен. Потому что естественно возникающая лавина кэша, она должна быть в определенное время, чтобы создать кэш централизованно, тогда в это время база данных может выдержать давление. Это не более чем периодическое давление на базу данных. С другой стороны, простой узла службы кэша вызывает непредсказуемое давление на сервер базы данных и, скорее всего, мгновенно перегрузит базу данных.
Пробой кэша
Пробой кэша, относится к ключу очень горячий, в безостановочном носить большой параллелизм, большой параллелизм сосредоточены на этой точке доступа, когда ключ в момент отказа, продолжали большой параллелизм на проникновение в кэш, напрямую запрашивать базу данных, как в барьер на долбил отверстие.
Я делаю проект электронной коммерции, товары станут "всплывающими".
На самом деле, в большинстве случаев такой прорыв очень сложно вызвать сокрушительное давление на сервер базы данных. Не многие компании достигли этого уровня. Поэтому прагматизм редактора заключается в том, чтобы основные товары были готовы раньше, чтобы кэш никогда не заканчивался. Даже если некоторые товары сами по себе бродили во всплывающем окне, достаточно просто установить для них прямое значение "никогда не истекать".
Путь прост, мьютексный ключ мьютексной блокировки действительно не может быть использован.
|
Предыдущая статьяMySql 8.0 Либо используйте безопасное соединение, указывайте RSA сервера...下一篇：докер контейнер контейнер доступ к внешним службам хоста
|
发表于 2019-11-19 09:55:04
избранное0 