vault backup: 2024-06-18 09:19:14
This commit is contained in:
parent
5e8540bcea
commit
61fdac61b2
@ -17,11 +17,11 @@ linked:
|
||||
|
||||
Система должна уметь выдерживать нагрузку и без кэша. Задача кэша ускорить ответ, а не держать нагрузку.
|
||||
|
||||
Кэширование основывается на [принципе локальности](Принцип%20локальности.md).
|
||||
Чаще всего реализуется на основе хэш-таблиц и использует [принцип локальности](Принцип%20локальности.md).
|
||||
|
||||
Чаще всего реализуется на основе хэш-таблиц.
|
||||
==Системы используемые для кэширования обычно не являются надежными, так что не следует хранить только там какие-то важные данные.==
|
||||
|
||||
==Системы используемые для кэширования обычно не являются надежными, так что не следует хранить только там какие-то важные данные.== Данные можно разделить на несколько категорий:
|
||||
Данные можно разделить на несколько категорий:
|
||||
- «**Можно потерять**». К этой категории относятся кэши выборок из базы данных. Потеря таких ключей не так страшна, потому что мы можем легко восстановить их значения, обратившись заново к backend’у. Однако частые потери кэшей приводят к излишним обращениям к БД.
|
||||
- «**Не хотелось бы потерять**». Здесь можно упомянуть счетчики посетителей сайта, просмотров ресурсов и т.п. Хоть и восстановить эти значения иногда напрямую невозможно, но значения этих ключей имеют ограниченный по времени смысл: через несколько минут их значение уже неактуально, и будет рассчитано заново.
|
||||
- «**Совсем не должны терять**». Кэш удобен для хранения сессий пользователей. Однако содержимое сессий не хотелось бы терять никогда – иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно кластеризовать систему кэширования, так вероятность потери снижается.
|
||||
|
Loading…
Reference in New Issue
Block a user