Технология жана инфраструктура → Кэш-деңгээл жана маалыматтарды сактоо

Кэш-деңгээл жана маалыматтарды сактоо

1) Эмне үчүн көп катмарлуу кэш керек

Кэш - бул "кымбат" подсистемаларга (DD, тышкы API, тармактар) барбастан жоопко кыска жол. Көп катмарлуу жүктү бөлүштүрөт: браузер → CDN/edge → колдонмо катмар → бөлүштүрүлгөн кэш → DD/сактоо. Максаттары: P95/P99 азайтуу, origin түшүрүп, күчтүү чокулары туруштук жана байт арзандатуу.

2) Кэш деңгээлдеринин картасы

1. Браузер: `Cache-Control`, `ETag`, `Last-Modified`, `stale-while-revalidate`.
2. CDN/Edge: TTL/ключ, Vary, Signed URLs, image-resize; tiered/shield.
3. API Gateway/Service Mesh: коопсуз GET боюнча кыска мөөнөттүү жооп кэш.
4. Колдонмо (in-process): LRU/LFU, "ысык" ачкычтар үчүн near-cache, миллисекунддар.
5. Бөлүштүрүлгөн кэш (Redis/Memcached): динамикасы үчүн негизги катмар.
6. Кэш DD: Pg/Innodb буферлер, PgBouncer multiplexing, materialized views.
7. Диск/объект stores: precomputed snapshots, blob кэш (мисалы, S3 + CDN).

Принцип: "колдонуучуга канчалык жакын болсо, TTL ошончолук кыска жана персоналдаштыруу азыраак болот; маалыматтар канчалык жакын болсо, консистенттик саясат ошончолук бай болот".

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

Cache-Aside (Lazy): Биз окуп → МИСС булагы жүктөп → кэш салып. Жөнөкөй, TTL көзөмөл берет.
Read-Through: колдонмо өзү булагы тартып кэш аркылуу окуйт. Саясатты борборлоштуруу ыңгайлуу.
Write-Through: жазуу кэш жана булагы дароо барат. консистенттүү, бирок жазуу боюнча кымбат.
Write-Back (Write-Behind): Кэшке жазабыз, булак асинхрондук түрдө жаңыланат (кезек). Жогорку ылдамдык, жеткирүү кепилдиги жана туруктуулук талап кылынат.
Refresh-Ahead: "жогорку" ачкычтар TTL аяктаганга чейин такташты.

Кайда: оюн карталары/каталогдору - cache-aside/read-through; эсептегичтер/алдыңкы такталар - write-back + CRDT/агрегациялар; валюталардын/лимиттердин маалымдамалары - башкарылуучу TTL менен read-through.

4) ачкычтар, сегменттөө жана нейминг

Шаблон: `domain:entity:{id}:v{schema}|region={R}|currency={C}|lang={L}`.
жоопту өзгөртүп гана ачкычка киргизүү (аймак, акча, тил, схема версия).
Схемаларды чыгаруу: шайкеш келбеген өзгөрүүлөр менен - массалык purge качуу, ачкычында 'vN' жогорулатуу.
Namespacing буюмдар/тенанттар боюнча: 'tenant: {t}:...' - multi-tenant үчүн маанилүү.
Bloom чыпкасы "ачкычтын болушу" булакка саякаттарды азайтышы мүмкүн.

5) TTL, сергектик жана майыптык

• статика (hashed файлдар): 30-365 күн + 'immutable';
• каталогдор/баннерлер: 5-60 мүнөт + 'stale-while-revalidate';
• алдыңкы такталар/котировкалар: 2-15 секунд;
• Маалымдамалар (валюталар/лимиттер): 1-10 мүнөт.
• майыптыгы окуялар: жарыялоо 'product. updated '→ чекиттик ачкычтын/префикстин майыптыгы.
• Tag-based purge: тегдер боюнча топтук тазалоо (бошотуу промо/каталогу).
• Soft-Expiry: TTL аяктагандан кийин эскирген 'stale' деп беребиз, ошол эле учурда жаңылайбыз (SWR/SIE).
• Versioned Keys> массалык purge: арзан жана коопсуз.

6) Stampede, "ысык" ачкычтар жана атаандаштык

• Single-flight (request coalescing): бир лидер ачкычты жаңылайт, калгандары күтүп турат.
• TTL Життер: бир заматта кыйрашы качуу, бүдөмүк.
• SWR жергиликтүү: мөөнөтү өтүп кеткен маанини колдонуучуга беребиз, фонунда жаңылайбыз.

• бир нече слотторго "ысык" ачкычты репликациялоо 'key # 1.. N' окуу менен бөлүштүрүлгөн;
• жараянынын эс near-cache;
• жогорку чейин prewarm/refresh-ahead (турнир/дан).
• Оор ачкычтар үчүн Concarrancy Update чеги.

7) консистенттүүлүк жана кросс катмарлары

Write-invalidate: булакка жазууда - тиешелүү ачкычтарды (pub/sub) синхрондуу түрдө майып кылуу.
Read-repair: айырмачылыктар туура мааниде кэш жаңыртуу.
Eventual vs Strong: критикалык акча иш түздөн-түз окуп/кыска TTL менен; UI-дисплей жана статистика - eventual.
CRDT/агрегаторлор: бөлүштүрүлгөн эсептегичтер/рейтингдер үчүн - "merge-safe" түзүмдөрү (G-Counter, агымдарда Top-K).
Каскаддык майыптык: жаңыртуу "оюн" майып карта + тизме + колдонуучу кэш сунуштар.

8) Сериалдаштыруу, кысуу жана формат

Форматтар: ProtoBof/MessagePack JSON тезирээк; CDN/браузер үчүн - JSON менен Brotli.
Redis кысуу: объектилер үчүн пайдалуу> 1-2 KB, бирок CPUга көз салуу.
Partial жооп/талап боюнча талаалар: аз байт → аз TTFB жана RAM.

9) алмаштыруу саясаты жана көлөмү

LRU (демейки) - коопсуз; LFU - "популярдуу" мазмун үчүн жакшы.
Ачкычтар/маанилердин өлчөмү: көзөмөлгө алуу (метриктер 'avg value size', 'max').
бир продукт бүт кэш "жеп" эмес, namespace/tenant боюнча квота.

10) Коопсуздук жана PII/PCI

Жеке/каржылык маалыматтар - CDN/edge жана жалпы катмарларда кэш жок; белгилерди/проекцияларды колдонуңуз.
Client-side крипто аркылуу Redis сезгич баалуулуктарды шифрлөө (TTL контролун жоготууга этият болуу менен).
Катуу ACL жана тармактарды изоляциялоо; белгиленген NAT/IP үчүн egress жөнөтүүчүлөргө.

11) Байкоо жана SLO кэш

• Hit Ratio (катмарлары жана префикстери боюнча), Origin Offload.
• TTFB/P95/P99 чейин/кийин кэш, Latency Redis.
• Evictions, OOM, keyspace hits/misses.
• Stampede rate (параллелдүү жаңыртуулардын үлүшү), refresh time.
• Stale served % и Freshness lag.

• Оюн каталогу: Hit Ratio ≥ 85%, TTFB P95 ≤ 150 ms (edge).
• API колдонмолор: Revalidation-хит ≥ 60%, P95 ≤ 200 ms.
• Redis: P99 операция ≤ 5 мс, evictions саатына 1% ашык эмес.

12) FinOps: кэш наркы

$/GB-ай RAM vs $/RPS origin: өзүн-өзү актоо чекитин санап.
Offload жана egress: CDN + Redis региондук-origin чыккан трафикти азайтат.
Image/WebP/AVIF жана denormisionalization көп байт үнөмдөө берет.
"Кымбат MISS" чеги: аналитика "Байт × MISS × аймак".

13) Мисалдар (фрагменттер)

13. 1 Cache-Aside менен single-flight (псевдокод)

python def get(key, ttl, loader):
val = redis. get(key)
if val: return val with single_flight (key): # only one updates val = redis. get (key) # double check if val: return val data = loader () # request to source redis. setex(key, ttl_with_jitter(ttl), serialize(data))
return data

13. 2 Окуя боюнча майыптыкты жарыялоо

json
{
"event": "game. updated",
"game_id": "g123",
"affected": ["catalog:list:region=TR", "game:card:g123:"]
}

Consumer каналга жазылган жана тиешелүү ачкычтар/тегдер 'DEL '/' PUBLISH' кылат.

13. 3 Схема жана жергиликтүү версия менен ачкыч

game:card:v2:id=g123    region=BR    currency=BRL    lang=pt-BR

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

1. кэш деңгээл картасы жана TTL-матрица (статикалык/жарым статикалык/API).
2. Neuming Keys: домен, схема версия, жергиликтүү/аймак/акча, tenant.
3. per-endpoint (aside/read-through/write-through/back) үлгү тандоо.
4. SWR/SIE, single-flight жана TTL-джиттер каршы stampede.
5. майып окуялар (pub/sub), топтор үчүн tag-purge.
6. "Ысык" ачкычтар жана чокулары алдында prewarm үчүн Near-cache.
7. Форматтар жана компрессия (protobuf/MsgPack, Brotli), өлчөмдү көзөмөлдөө.
8. LRU/LFU саясаты, namespace/tenant боюнча квота.
9. SLO/метрики: hit ratio, latency, evictions, stale %, freshness lag.
10. Коопсуздук: no-store үчүн жеке, tokenization, тармак/ACL.

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

'no-cache' "учурда" жана TTL баш тартуу - нөл offload.
ачкычы бардык query/баш → кардиналдык жарылуу камтыйт.
Массалык purge "бардык CDN/Redis" ар бир релизинде.
stampede коргоонун жоктугу жана "жогорку ачкычтар" бир жолку мөөнөтү.
Бирдиктүү жалпы Redis эч кандай квота/обочолонуу; "ысык" tenant бүт кэш жейт.
edge/CDN боюнча жеке жоопторду кэштоо.
Эч кандай телеметрия freshness/evictions → сокур башкаруу.

16) Контекст iGaming/Fintech: практикалык ноталар

Лидборддор/рейтингдер: TTL 2-10 с, aggregate-агымдары + CRDT, SWR бузулганда.
Оюн каталогу/баннерлер: CDN + Redis; ачкыч: аймак/акча/тил; "promo: update".
Төлөм статусу: жазуу жолунда кэшсиз; окуу - кыска TTL (≤ 3-5 с) же түздөн-түз суроо.
KYC/AML жооптор: эмес PII туундуларды кэш (статустар), Redis сүрөттөрдү/документтерди сактоо эмес.
VIP жол: өзүнчө namespace/бассейн Redis, артыкчылыктуу тейлөө.

Жыйынтык

Күчтүү кэш стратегиясы - бул деңгээл архитектурасы, туура жаңыртуу үлгүлөрү, ойлонулган TTL/майыптык, stampede туруктуулугу, тыкан ачкычтар жана версиялар, ошондой эле байкоо жана FinOps. Бул принциптерди сактоо менен, сиз P95/P99 куйруктарын турукташтырып, булактарга жүктү азайтып, миллисекунддун болжолдуу наркын аласыз - бул продукт жана бизнес үчүн эң маанилүү жерде.