From 293900bece0077d11e65dcfa669b906742b9fc18 Mon Sep 17 00:00:00 2001 From: Struchkov Mark Date: Sat, 14 Sep 2024 22:17:56 +0300 Subject: [PATCH] =?UTF-8?q?=D0=98=D0=BD=D0=B2=D0=B0=D0=BB=D0=B8=D0=B4?= =?UTF-8?q?=D0=B0=D1=86=D0=B8=D1=8F=20=D0=BA=D1=8D=D1=88=D0=B0.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- dev/architecture/highload/Инвалидация кэша.md | 8 ++++---- education/Метапознание.md | 2 +- health/disease/Синдром беспокойных ног.md | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/dev/architecture/highload/Инвалидация кэша.md b/dev/architecture/highload/Инвалидация кэша.md index 8a8df711..7dd5c660 100644 --- a/dev/architecture/highload/Инвалидация кэша.md +++ b/dev/architecture/highload/Инвалидация кэша.md @@ -19,7 +19,6 @@ linked: - При малом TTL будет высокий [CacheMissRate](CacheMissRate.md) - При большом TTL данные могут быть не консистентны - Инвалидация по событию - - Удаляем старые данные при изменении в базе или по событию от кафки. - Опасно из-за риска мгновенной инвалидации и сопутствующей [[Перестройка кэша|перестройки кэша]] - Использование [[../../algorithm/Алгоритмы вытеснения|алгоритмов вытеснения]] @@ -29,11 +28,12 @@ linked: Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари. При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. В оценке эффективности кэша поможет метрика [[CacheMissRate]]. +## Инвалидация по событию +В этом случае мы удаляем данные кэша по какому-то событию. Например, при вызове метода обновления данных можно удалить кэш, который связан с этими данными. В некоторых случаях можно не удалять, а сразу класть новые данные в кэш, если понимаете, что они скоро потребуются. -Если просто установить TTL, то спустя какое-то время он истечет и данные будут удалены, но что если к ним постоянно обращаются. В некоторых случаях я использую подход, при котором при запросе данных из кэша проверяется оставшийся TTL, и если он меньше, чем некоторое значение, то TTL устанавливается заново. - -Данные остаются в кэше, если ими активно пользуются. В таком случае при обновлении данных, необходимо вручную положить новые данные или инвалидировать кэш по событиям. +Инвалидацию по событию можно комбинировать с TTL. В таком случае при запросе данных из кэша можно проверять оставшееся время жизни, и если оно меньше, чем некоторое заданное значение, то установить TTL заново. Таким образом данные остаются в кэше, если ими активно пользуются. +Пример реализации механизма обновления TTL на Lua: ```lua local key = KEYS[1]; local threshold = tonumber(ARGV[1]); diff --git a/education/Метапознание.md b/education/Метапознание.md index 5cbd0982..66d13554 100644 --- a/education/Метапознание.md +++ b/education/Метапознание.md @@ -3,7 +3,7 @@ aliases: - метапознание tags: - maturity/🌱 -date: "[[2023-10-28]]" +date: 2023-10-28 zero-link: - "[[../meta/zero/00 Образование|00 Образование]]" parents: diff --git a/health/disease/Синдром беспокойных ног.md b/health/disease/Синдром беспокойных ног.md index b40ca788..f0438e6c 100644 --- a/health/disease/Синдром беспокойных ног.md +++ b/health/disease/Синдром беспокойных ног.md @@ -3,7 +3,7 @@ aliases: - СБН tags: - maturity/🌱 -date: "[[2023-10-26]]" +date: 2023-10-26 zero-link: - "[[../../meta/zero/00 Здоровье|00 Здоровье]]" parents: