vault backup: 2024-06-18 09:19:14

This commit is contained in:
Struchkov Mark 2024-06-18 09:19:14 +03:00
parent 5e8540bcea
commit 61fdac61b2
No known key found for this signature in database
GPG Key ID: A3F0AC3F0FA52F3C

View File

@ -17,11 +17,11 @@ linked:
Система должна уметь выдерживать нагрузку и без кэша. Задача кэша ускорить ответ, а не держать нагрузку.
Кэширование основывается на [принципе локальности](Принцип%20локальности.md).
Чаще всего реализуется на основе хэш-таблиц и использует [принцип локальности](Принцип%20локальности.md).
Чаще всего реализуется на основе хэш-таблиц.
==Системы используемые для кэширования обычно не являются надежными, так что не следует хранить только там какие-то важные данные.==
==Системы используемые для кэширования обычно не являются надежными, так что не следует хранить только там какие-то важные данные.== Данные можно разделить на несколько категорий:
Данные можно разделить на несколько категорий:
- «**Можно потерять**». К этой категории относятся кэши выборок из базы данных. Потеря таких ключей не так страшна, потому что мы можем легко восстановить их значения, обратившись заново к backendу. Однако частые потери кэшей приводят к излишним обращениям к БД.
- «**Не хотелось бы потерять**». Здесь можно упомянуть счетчики посетителей сайта, просмотров ресурсов и т.п. Хоть и восстановить эти значения иногда напрямую невозможно, но значения этих ключей имеют ограниченный по времени смысл: через несколько минут их значение уже неактуально, и будет рассчитано заново.
- «**Совсем не должны терять**». Кэш удобен для хранения сессий пользователей. Однако содержимое сессий не хотелось бы терять никогда иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно кластеризовать систему кэширования, так вероятность потери снижается.