From 61fdac61b2eed00770028b2e617ea0ee0829d682 Mon Sep 17 00:00:00 2001 From: Struchkov Mark Date: Tue, 18 Jun 2024 09:19:14 +0300 Subject: [PATCH] vault backup: 2024-06-18 09:19:14 --- _inbox/Кэширование.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_inbox/Кэширование.md b/_inbox/Кэширование.md index 5f5bc9f4..7c3e9175 100644 --- a/_inbox/Кэширование.md +++ b/_inbox/Кэширование.md @@ -17,11 +17,11 @@ linked: Система должна уметь выдерживать нагрузку и без кэша. Задача кэша ускорить ответ, а не держать нагрузку. -Кэширование основывается на [принципе локальности](Принцип%20локальности.md). +Чаще всего реализуется на основе хэш-таблиц и использует [принцип локальности](Принцип%20локальности.md). -Чаще всего реализуется на основе хэш-таблиц. +==Системы используемые для кэширования обычно не являются надежными, так что не следует хранить только там какие-то важные данные.== -==Системы используемые для кэширования обычно не являются надежными, так что не следует хранить только там какие-то важные данные.== Данные можно разделить на несколько категорий: +Данные можно разделить на несколько категорий: - «**Можно потерять**». К этой категории относятся кэши выборок из базы данных. Потеря таких ключей не так страшна, потому что мы можем легко восстановить их значения, обратившись заново к backend’у. Однако частые потери кэшей приводят к излишним обращениям к БД. - «**Не хотелось бы потерять**». Здесь можно упомянуть счетчики посетителей сайта, просмотров ресурсов и т.п. Хоть и восстановить эти значения иногда напрямую невозможно, но значения этих ключей имеют ограниченный по времени смысл: через несколько минут их значение уже неактуально, и будет рассчитано заново. - «**Совсем не должны терять**». Кэш удобен для хранения сессий пользователей. Однако содержимое сессий не хотелось бы терять никогда – иначе пользователей на сайте будет «разлогинивать». Как попытаться избежать? Можно кластеризовать систему кэширования, так вероятность потери снижается.