Кэш стратегиялары

1) Эмне үчүн кэш жана кайда

• ылдамдыгы (p95/p99 төмөн), наркы (аз egress/CPU), туруктуулук (аз жогорку көз карандылык).
• Чокуларды тегиздөө жана "ызы-чуу кошуналардан" обочолонуу.

1. Кардар (браузер/мобилдик) - HTTP кэш, IndexedDB, local storage.

2. Edge/CDN - POP түйүндөрү колдонуучуга жакын, статиканы жана API бөлүгүн кэш.

3. L7-шлюз/Reverse-прокси - Nginx/Envoy/Varnish (микрокеш, SWR).

4. Тейлөө кэш - Redis/кластердин ичинде Memcached.

5. Процесс ичиндеги - in-memory (Caffeine/Guava/LRU-map).

6. БДдагы кэш - материалдык түшүнүктөр, экинчилик индекстер.

Эреже: керектөөчүгө мүмкүн болушунча жакын кэш, бирок чындыкты бир жолу сактаңыз.

2) Кэш үлгүлөрү

2. 1 Cache-aside (“lazy loading”)

Колдонмо биринчи кэш окуйт; ката кетиргенде - булактан, анан кэшке жазат.
Артыкчылыктары: жөнөкөйлүк, башкаруу. Кемчиликтери: муздак баштоо, карама-каршы терезелер.

2. 2 Read-through

Окуу дайыма кэш аркылуу, ал өзү ката болгондо булакка барат (китепкана/прокс катмары).
TTL/serilization саясатын борборлоштуруу үчүн ыңгайлуу.

2. 3 Write-through / Write-back (write-behind)

Write-through: кэш жазуу жана булагы синхрондуу → ырааттуулук жогору, жашыруун жогору.
Write-back: кэш жаздыруу, булагы → тез, бирок жоготуу жана чыр-чатактар ​ ​ коркунучу үчүн асинхрондук Flash жазуу.

2. 4 Refresh-ahead (proactive)

Алдын ала "жакында TTL аяктайт" жана stampede алдын алуу алкагында ачкычын тактоо.

2. 5 Negative caching

кыска TTL боюнча кэш "эч кандай маалымат/404/бош" булагы боюнча жүктү азайтат.

2. 6 Micro-caching

Өтө кыска TTL (0. 5-5 с) "дээрлик динамикасы" үчүн L7 боюнча (тизмелери, негизги) - кескин куйруктарын азайтат.

3) HTTP кэш: аталыштары жана контролдоо

3. 1 Негизги аталыштар

`Cache-Control`: `max-age`, `s-maxage` (для shared кэшей), `public/private`, `no-store`, `stale-while-revalidate`, `stale-if-error`.
Валидаторлор: 'ETag', 'Last-Modified'.
шарттары менен суроолор: 'If-None-Match', 'If-Modified-Since' → 304 Not Modified.

3. 2 Vary жана ачкычтар

'Vary: Accept-Encoding, Authorization, Cookie, Accept-Language' - кэштин ар кандай варианттарын түзөт. "Vary" минималдаштыруу үчүн эмес, "жардыруу" кардиналдык.

3. 3 Мисал HTTP жооп

Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60
ETag: "a1b2c3"
Vary: Accept-Encoding

4) ачкычтарды жана TTL долбоорлоо

4. 1 ачкычтары

Структуралаштырыңыз: 'tenant: user: {id}: profile: v3' (схеманын версиясын кошуңуз).
PII ачкычында качуу.
Коллекциялар үчүн - ачкыч + суроо параметрлери (нормалдаштырылган жана иреттелген).

4. 2 TTL жана ырааттуулук

Кыска TTL айырмачылыктарды азайтат, бирок каталарды көбөйтөт.
Критикалык маалыматтар үчүн - валидаторлор ('ETag') жана SWR (stale-while-revalidate).
сейрек өзгөрүүлөр үчүн - узак TTL + "бомба" майыптыгы.

4. 3 Версиялоо/Бастинг

туура эмес өзгөрүүлөр менен - префикс/ачкычтын нускасын өзгөртүү ('v2 → v3').
Статикалык ресурстар үчүн - файлдын аталышындагы content hash.

5) Майыптык: стратегиялар жана практикалар

5. 1 Түздөн-түз алып салуу

'DEL key '/' PURGE' прокси. Коркунуч: алып салуу жана көп окурмандардын ортосундагы жарыш.

5. 2 Tags/Surrogate keys

Документти тегдер топтому менен байланыштырыңыз (категория/автор). Майыптык - тег боюнча.
В Varnish/Edge — `Surrogate-Key: article:42 tag:author:7` + `BAN tag:author:7`.

5. 3 Event-driven майыптыгы

Pub/Sub (Kafka/NATS): булагы өзгөргөндө - окуя "invalidate" жарыялайт.
Кэш-менеджерлер ачкычтарды угат жана өчүрөт/жаңыртат.

5. 4 Эки фазалуу

Адегенде ачкычты эскирген деп белгилейбиз (жумшак TTL), стейлерди тейлейбиз, фонунда жаңылайбыз жана атомдук түрдө алмаштырабыз.

6) stampede/dogpile жана ысык ачкычтар менен күрөшүү

6. 1 Request coalescing (singleflight)

Бир продюсер ачкычты жаңыртып жатат, калгандары натыйжаны күтүп жатышат (мьютекс/лейбл "жаңыланып жатат").

6. 2 Jitter к TTL

Синхрондуу шишип кетпөө үчүн TTLге кокустукту (10-20% ±) кошуңуз.

6. 3 Soft-TTL + hard-TTL

soft-TTL чейин кызмат кэш, параллелдүү триггерим refresh; боюнча hard-TTL - биз ката деп эсептейбиз.

6. 4 ысык ачкычтар

жалпы үстүнөн жергиликтүү кэш (two-tier).
Hot ачкычты бир нече шардага жана рандомдук тандоого репликациялоо (гана read-only үчүн).
Белгилүү бир ачкычты жаңыртуу үчүн Rate limit.

6. 5 Redis + Lua мисал (singleflight эскиз)

lua
-- SETNX lock with TTL to avoid deadlocks local ok = redis. call("SET", KEYS[1], "1", "NX", "EX", ARGV[1])
if ok then return "LOCKED"
else return "WAIT"
end

7) алмаштыруу саясаты жана кэш кабыл алуу

7. 1 Eviction

LRU: жөнөкөй жана жергиликтүү үчүн жакшы.
LFU: "узак" ысык ачкычтар менен жакшы.
ARC/TinyLFU: баланс recency/frequency.

7. 2 Admission (киргизүү)

ири сейрек кездешүүчү объектилерди (TinyLFU/Bloom-Filters) киргизбеңиз.
"Көлөм/жашыруун" чегинде чоң баалуулуктарды (LZ4/Zstd) кысуу.

8) Шардана жана топология

8. 1 Consistent hashing

Ноддор боюнча ачкычтарды туруктуу бөлүштүрөт, кластердин өсүшү/кысылышы менен кыймылдарды азайтат.

8. 2 Топология Redis/Memcached

Redis Cluster (Slots/Шарлар), Sentinel (Feylover), репликация read-only.
Memcached - кардар-сайт шардинг (ketama hashing), Server деъгээлинде репликация жок.

8. 3 Жергиликтүү + бөлүштүрүлгөн

Cascade: in-proc (микро-TTL/LRU) → Redis (TTL узун) → булак.
TTL жана кэш-валидаторлор менен сак болуңуз.

9) Edge, CDN жана L7 кэш

9. 1 Micro-cache на Nginx

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:100m inactive=10m;
map $request_method $skip_cache { default 0; POST 1; PUT 1; DELETE 1; }

server {
location /api/list {
if ($skip_cache) { add_header Cache-Control "no-store"; }
proxy_cache api;
proxy_cache_valid 200 2s;       # micro-cache proxy_cache_use_stale error timeout updating;
proxy_cache_background_update on;   # SWR add_header X-Cache $upstream_cache_status;
proxy_pass http://upstream;
}
}

9. 2 Envoy (SWR жана шарттары)

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. http. cache. file_system_http_cache. v3. FileSystemHttpCacheConfig cache_path: "/var/cache/envoy"

9. 3 Varnish (Surrogate keys)

'Surrogate-Key' жана 'ban' колдонуңуз.

10) Кэш жана маалыматтардын шайкештиги

10. 1 Read-your-writes

Колдонуучунун профилдери/корзиналары үчүн же кыска TTL, же кэш аркылуу жазууну (write-through), же кардардын маркировкасын (жазуудан кийин N секундага айланып өтүүнү) камсыз кылыңыз.

10. 2 Eventual vs Strong

сунуш/аналитикалык үчүн - eventual + узун TTL.
Акча/заказ статусу үчүн - кыска TTL, валидация, кээде маанилүү жолдордо кэшсиз.

10. 3 Инварианттар

Катуу TTL жана кайра текшерүү жок, коопсуздук/ACL таасир талааларды кэш жок.

11) Байкоо, SLO жана башкаруу

11. 1 Метрика

hit_ratio (общий и per-route), byte_hit_ratio, miss_rate.
stampede_prevented_total, refresh_ahead_total, ban/purge_total.
Latentity: p50/p95/p99 vs булагы кэш.
hot_keys_topN жана алардын QPS/байт.

11. 2 Логи жана Tracking

Логин 'X-Cache: HIT/MISS/STALE/UPDATING'.
Трестерде жооп булагын белгилеңиз ('cache = true', 'tier = edge' service 'local').

11. 3 SLO ыкмасы

Мисалы: "үчүн API/catalog p99 ≤ 250 ms, cache hit ≥ 85%, stampede ≤ 0. 1% суроо".

11. 4 Runbooks

"Каталар өсүп жатат" → TTL текшерүү, жылытуу/майыптык, hot-keys, кэш өлчөмү жана кабыл алуу саясаты.

12) Коопсуздук жана көп тенанттуулук

tenant-id ачкычтар (жана 'Vary' HTTP менен).
Жеке жоопторду 'public' деп кэштоого болбойт.
сезимтал маалыматтар менен кэш шифрлөө же гана эмес PII/ID сактоо.

13) типтүү Recipes

13. 1 Каталог/лента (дээрлик динамикасы)

Edge-микрокеш 1-3 с + SWR, ичинде - Redis 15-60 с, жаңылануу окуялары боюнча майыптык.

13. 2 Колдонуучунун профили

Cache-aside менен TTL 30-120 с, bypass 5-10 с кийин профиль (cookie/heder), же write-through.

13. 3 алмашуу курсу/колдонмо

Узун TTL (мүнөт-саат) + жаңы маалыматтарды жарыялоодо максаттуу майып; шарттуу GET үчүн 'ETag'.

13. 4 Издөө натыйжалары

Edge-микрокеш 1-2 с, ичинде - refresh-ahead жана coalescing, негизги query-параметрлерин нормалдаштыруу.

14) Анти-үлгүлөрү

майыптыгы жок кэш: TTL гана үмүт → узак терезелер маанисиз.
Гигант 'Vary': "жарылуу" параметрлери → төмөн hit-rate.
prod/experiments → булганышы үчүн бирдиктүү кэш.
TTL аяктагандан кийин булакта stampede → чокулардан коргоо жок.
накталай акча/укуктар/ACL катуу кепилдиктери жок.
Компрессия "бир катар" - кошумча CPU, чакан объектилерде p99 начарлашы.

15) Киргизүү чек-тизмеси

• Кэш деңгээлдерин жана алардын максаттарын аныктаңыз (edge/service/local).
• ачкычтарды долбоорлоо (чыгаруу, tenant, параметрлерин нормалдаштыруу).
• Үлгү тандоо (cache-aside/read-through/refresh-ahead).
• TTL/soft-TTL/jitter, SWR кирет.
• coalescing/singleflight, stampede коргоо ишке ашыруу.
• майып уюштуруу (окуялар, теги, purge/ban).
• hit-ratio/жашыруун жана dashboard 'X-Cache' параметрлерин киргизиңиз.
• ысык ачкычтар менен жүктөө сыноолорду жүргүзүү.
• SLO жана runbooks жазып.
• Коопсуздук/tenant-обочолонуу жана 'Vary' текшерүү.

16) FAQ

Q: тандоо үчүн эмне - cache-aside же read-through?
A: жөнөкөй кызматтар үчүн - cache-aside. Борборлоштуруу жана бирдиктүү саясат керек - read-through.

Q: Кантип оптималдуу TTL түшүнүүгө болот?
A: жол эскирүү, тактоо жыштыгы жана максаттуу hit-rate баштап; jitter кошуу жана p95/p99/наркы байкоо.

Q: Качан туура write-back?
A: eventual-консистенттүүлүк алгылыктуу жана "кошумча" үчүн ишенимдүү кезек/журнал бар жогорку жүктөлгөн агымдар үчүн.

Q: Уруксат берилген жоопторду кэштоого болобу?
A: Ооба, бирок 'private' жана/же tenant/колдонуучуну ачкычка/' Vary 'деп белгилеңиз. truly-private үчүн - кардар кэш.

Q: Кантип кэш жылытат?
A: популярдуу ачкычтардын тизмеси, Background-Wormer, ийбадатканалардан реплика, чыгаруу/чокусуна чейин жылытуу (кара жума ж.б.).

17) Натыйжалары

Натыйжалуу кэш - бул ачкычтын дизайны + акылга сыярлык TTL + иш-чаралардын майыптыгы, SWR/refresh-ahead жана stampede коргоо менен күчөтүлгөн туура тандалган үлгү. Cache деңгээл (кардар/edge/кызматы), байкоо жана SLO кошуу - жана туруктуу кечигүү куйруктарын алуу, алдын ала баасы жана жогорку жүктөрдү туруктуулук.