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

Кэш-деңгейлер және деректерді сақтау

1) Неге көп қабатты кэш қажет

Кэш - бұл «қымбат» кіші жүйелерге (ДБ, сыртқы API, желілер) бармай жауаптың қысқа жолы. Көп қабаттылық жүктемені таратады: браузер → CDN/edge → қолданбалы қабат → таратылған кэш → ДБ/сақтау орны. Мақсаттары: 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. БД кэштері: Pg/Innodb буферлері, PgBouncer multiplexing, materialized views.
7. Дискілік/нысандық сторлар: precomputed snapshots, blob-кэш (мысалы, S3 + CDN).

Қағидат: "пайдаланушыға неғұрлым жақын болса - ТТЛ соғұрлым қысқа және персоналдандыру азырақ; деректерге неғұрлым жақын болса, соғұрлым консистенттілік саясаты бай болады".

3) Кешіктіру үлгілері

Cache-Aside (Lazy): оқимыз → MISS кезінде көзден жүктейміз → кэшке саламыз. Қарапайым, 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, жаңалық және мүгедектік

• статика (хеширленген файлдар): 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 шыңдар алдында (турнирлер/матчтар).
• Ауыр кілттер үшін конкарренсиге арналған жаңарту лимиттері.

7) Консистенттілік және кросс-қабаттар

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

8) Серияландыру, қысу және пішім

Пішімдер: протобуф/MessagePack JSON тезірек; CDN/браузер үшін - JSON Brotli.
Redis компрессиясы: объектілер үшін тиімді> 1-2 КБ, бірақ CPU-ны қадағалаңыз.
Partial responses/талап бойынша өрістер: аз байт → аз TTFB және RAM.

9) Ығыстыру саясаты және

LRU (әдепкі) - қауіпсіз; LFU - «танымал» контент үшін жақсы.
Кілттердің/мәндердің өлшемі: бақылауда ұстаңыз ('avg value size', 'max').
Бір өнім бүкіл кэшті «жемеуі» үшін namespace/tenant бойынша квоталар.

10) Қауіпсіздік және PII/PCI

Жеке/қаржылық деректерді CDN/edge және жалпы қабаттарда кешіктірмеу; белгілерді/проекцияларды пайдаланыңыз.
client-side crypto (TTL-бақылау шығындарын сақтай отырып) арқылы Redis-тегі сезімтал мәндерді шифрлау.
Қатаң ACL және желілерді оқшаулау; провайдерлерге egress үшін тіркелген NAT/IP.

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 мс (edge).
• API-анықтамалықтар: Revalidation-hit ≥ 60%, P95 ≤ 200 мс.
• Redis: P99 операциясы ≤ 5 мс, evictions сағатына 1% -дан аспайды.

12) FinOps: кэш құны

$/GB-ай RAM vs $/RPS origin: өзін-өзі ақтайтын нүктені есептеңіз.
Offload және egress: CDN + Redis origin аймағынан шығатын трафикті азайтады.
Image/WebP/AVIF және теңдестірулер байтты барынша үнемдейді.
«Қымбат 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:"]
}

Консьюмер арнаға жазылды және тиісті кілттер/тегтерге 'DEL '/' PUBLISH' жасайды.

13. 3 Схема және локаль нұсқасы бар кілт

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

14) Енгізу чек-парағы

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

15) Қарсы үлгілер

'no-cache' «жағдайға» және TTL-ден бас тарту - нөлдік offload.
Кілт барлық query/тақырыптарды қамтиды → түбегейлі жарылыс.
Әрбір релизде жаппай purge «барлығы CDN/Redis».
Stampede қорғанысының болмауы және «топ-кілттердің» бір мезгілде аяқталуы.
Бірыңғай жалпы Redis квотасыз/оқшаулаусыз; «ыстық» tenant бүкіл кешті жейді.
edge/CDN дербес жауаптарын кешіктіру.
freshness/evictions → соқыр басқару телеметриясы жоқ.

16) iGaming/финтех контекст: практикалық ноталар

Көшбасшы борттар/рейтингтер: TTL 2-10 с, aggregate-ағындар + CRDT, SWR сәтсіздіктер кезінде.
Ойындар/баннерлер каталогы: CDN + Redis; кілт: өңір/валюта/тіл; «promo: update» тегтері бойынша мүгедектік.
Төлем мәртебелері: жазу жолында кэшсіз; оқу - қысқа TTL (3-5 с ≤) немесе тікелей сұрау.
KYC/AML жауаптары: non-PII деривативтерін кешіктіріңіз (статустар), Redis бағдарламасында суреттерді/құжаттарды сақтамаңыз.
VIP жолы: жеке namespace/Redis пулы, басым қызмет көрсету.

Жиынтығы

Күшті кэш-стратегия - деңгейлердің архитектурасы, дұрыс жаңарту үлгілері, ойластырылған TTL/мүгедектік, stampede төзімділік, ұқыпты кілттер мен нұсқалар, сондай-ақ бақылау мен FinOps. Осы қағидаларды басшылыққа ала отырып, сіз P95/P99 қалдықтарын тұрақтандырады, көздерге түсетін жүктемені қысқартады және миллисекунд құнын алады - бұл өнім мен бизнес үшін ең маңызды жерде.