Кешендеу архитектурасы: Redis, Memcached

Кешендеу архитектурасы: Redis, Memcached

1) Қашан және неліктен кеш

Мақсаттары: жасырындылықты төмендету, ДБ/PSP/сыртқы API жүктемесін түсіру және шыңдарды жұмсарту.
Кештердің қабаттары көбінесе көп деңгейлі: in-process (L1) → service-level (Redis/Memcached L2) → edge/CDN. Ішкі кэш «ыстық» оқуларды жылдамдатады, L2 - сервистер үшін ортақ, edge - көпшілік мазмұн үшін.

2) Redis vs Memcached - қысқаша

Ереже: Егер күрделі деректер құрылымы, персистенттілік, pub/sub/стримдер/скрипттер қажет болса, Redis бағдарламасын алыңыз. Егер супер қарапайым, жылдам, арзан KV кэш қабаты durability болмаса - Memcached.

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

3. 1 Cache-aside (lazy)

Бағдарлама кэштен оқиды → қате → ДБ оқиды → TTL кэшіне салады.

Қарапайым бақылау TTL, кэшке тәуелсіз. − Қателіктер кезінде «дауыл» болуы мүмкін.

3. 2 Read-through

Клиент/прокси жаңылыс кезінде origin-ді өзі тартып, кэшке салады.

Орталықтандырылған логика. − Күрделі инфрақұрылымдық.

3. 3 Write-through / Write-behind

Write-through: алдымен кэшке, содан кейін ДБ жазу.
Write-behind: кезекке жазылу, ДБ-да асинхронды флаш (әрлеу кезінде ықтимал жоғалту - журнал қажет).

3. 4 Two-tier (L1+L2)

L1 (in-process) қысқа TTL және soft TTL, L2 (Redis/Memcached) - «кештің шындығы». pub/sub арқылы мүгедектік.

4) TTL, дауыл және консистенттілік

TTL: деректерді өзгерту жиілігіне жақын қойыңыз. Ыстық кілттер үшін TTL (jitter) рандомизациясын пайдаланыңыз: 'ttl = base ± rand (0.. base0. 1) '- синхронды ағындарды алады.

• Singleflight: тек бір ғана процесс мәнді қайта генерациялайды (Lua мысалын қараңыз).
• Soft-TTL + background refresh: 'soft _ ttl' -ден кейін ескіргендерін (stale) беріп, фонымен жаңартыңыз.
• Semaphore/lock: `SET key:lock value NX PX=2000`.
• Near-stale: жауаптардың API үшін 'stale-while-revalidate' (8-бөлімді қараңыз).

5) Кілттер, неймспейстер, сериалдандыру

5. 1 Кілттерді атау

Үлгі: '{domain}: {entity}: {id}: {field}'

• `user:profile:42` `catalog:product:1001:v2` `psp:rates:2025-11-03`

Схеманың нұсқасын қосыңыз (': v2') - бұл жаппай мүгедектікті жеңілдетеді.

5. 2 «Кеңістік нұсқасы» арқылы неймспейстер

ns: catalog = 17 'кілтін ұстаңыз. Нақты кілттер: 'catalog: 17: product: 1001'. Каталогтың жаһандық мүгедектігі үшін 'ns: catalog' дегенді енгізіңіз.

5. 3 Серияландыру/компрессия

JSON - ыңғайлы, бірақ ауыр. MessagePack/CBOR бағдарламасын пайдаланыңыз.
Үлкен payload (> 1-2 KB) үшін компрессияны (LZ4/ZSTD) қосыңыз. Redis - клиент жағында.

6) Ыстық кілттер және шардирлеу

• Replicated read pattern: 'hot: k: 1.. N' бірнеше shard кілттерін қайталаңыз, оқығанда кездейсоқ таңдаңыз.
• Local L1: мүгедектікке жазылумен процесті жадта сақтаңыз.

• Redis Cluster - нормативтік (16384 hash-слоттар).
• Memcached - клиенттік консистенттік хеш.
• Hash-tag Redis '{...}' кілттерді теру үшін слотты белгілейді: 'user: {42}: profile' және 'user: {42}: limits' бір шарда болады.

7) Ығыстыру саясаты және өлшемдері

Redis `maxmemory-policy`: `allkeys-lru`, `volatile-lru`, `allkeys-lfu`, `noeviction` и т. д. Кэш үшін әдетте 'allkeys-lru '/' allkeys-lfu'.
Memcached — LRU на item-slab.
Кілт пен value өлшемі: max item size (Memcached әдепкі 1 МБ, тюнинг slab).
Жадының асып кетуі болжамды түрде деградациялануы тиіс: белсенді жолда 'noeviction' емес.

maxmemory 32gb maxmemory-policy allkeys-lfu hz 50 tcp-keepalive 60

8) Дауылдан қорғау паттерндері - код

8. 1 Redis Lua singleflight (псевдо)

lua
-- KEYS[1] = data_key, KEYS[2] = lock_key
-- ARGV[1] = now_ms, ARGV[2] = soft_ttl_ms, ARGV[3] = hard_ttl_ms, ARGV[4] = lock_ttl_ms local payload = redis. call("GET", KEYS[1])
if payload then local meta = redis. call("HGETALL", KEYS[1].. ":meta")
local last = tonumber(meta[2] or "0")
if tonumber(ARGV[1]) - last < tonumber(ARGV[2]) then return { "HIT", payload }
end if redis. call ("SET," KEYS [2], "1," "NX," "PX," ARGV [4]) then return {"REFRESH," payload} - one worker updates, the rest give stale end return {"STALE," payload}
end if redis. call("SET", KEYS[2], "1", "NX", "PX", ARGV[4]) then return { "MISS", nil }
end return { "BUSY", nil }

8. 2 Node. js cache-aside (оңайлатылған)

js const v = await redis. get(key);
if (v) return decode(v);
const lock = await redis. setNX(key+":lock", "1", { PX: 1500 });
if (lock) {
const fresh = await loadFromDB(id);
await redis. set(key, encode(fresh), { EX: ttl, NX: false });
await redis. del(key+":lock");
return fresh;
} else {
await sleep(60);           // short backoff const retry = await redis. get (key) ;//give someone's already filled return decode (retry);
}

9) Мүгедектік және келісу

Оқиға бойынша: ДБ-да өзгерген кезде 'invalidate' оқиғасын жариялаңыз: {ns}: {id} '→ жазылушылар кілттерді жояды.
Таймер бойынша: жиі өзгеретін деректер үшін қысқа TTL.
Нұсқалау: 'ns:' кілттерін қараңыз.
Outbox: мүгедектікті жеткізу кепілдігі (оқиға/топик, ретра).
Кэшпен операциялардың ұқсастығы: 'SETXX/SETNX', нұсқалар ('etag') және инкремент үшін хэш өрістерін пайдаланыңыз.

10) Репликация, кластер, failover

10. 1 Redis

Sentinel: автоматты failover master-replica (стейтFUL IP/аты).
Cluster: шардалау + автоматты failover; клиенттер 'MOVED/ASK' редакторларын қолдауы тиіс.
AOF/RDB: кэш үшін әдетте 'appendfsync everysec' персистентсіз (таза кэш ретінде) болады.

10. 2 Memcached

Қораптан репликалау жоқ. Сенімділік - көп бұрышты шард + n '(client-side) қайталау арқылы.
Нода құлаған кезде - қателіктердің өсуі және кешті «қайта оқыту».

10. 3 K8s және желілік аспектілер

Redis/Memcached pod 'дардың жиі қайта берілуін ұнатпайды; StatefulSet + PVC/POD IP тіркелген АЗ антиподтарын пайдаланыңыз.
PodDisruptionBudget және TopologySpreadConstraints орнатыңыз.

11) Транзакциялар, скрипттер және атомарлық (Redis)

INCR/DECR, HINCRBY - есептеуіштер, квоталар, rate-limits (тек persist ескеріңіз).
MULTI/EXEC - атомдық командалар бумасы.
Lua (EVAL) - жарыссыз read-modify-write.
Pipeline - RTT азайтады (әсіресе желілік хопта).

lua
-- KEYS[1]=bucket, ARGV[1]=capacity, ARGV[2]=refill_rate_per_sec, ARGV[3]=now_ms
-- Returns 1 if the token is issued, otherwise 0

12) Кезектер, pub/sub және Streams (Redis)

Pub/Sub: мүгедектік, сигналдар. Сақтаусыз, тек онлайн тыңдаушылар.
Streams: расталған оқиғалар кезегі (ACK), тұтынушылар тобы, ретра - write-behind/fan-auts үшін қолайлы.
Lists ('BRPOP'): қарапайым кезектер.
Redis-ті бэкапсыз «бірыңғай шина» ретінде пайдаланбаңыз - бұл кэш/жылдам шина, Kafka емес.

13) Қауіпсіздік және қол жетімділік

/ VPC, mTLS желілерін ingress-деңгейінде оқшаулау, ACL/парольдер ('requirepass '/ACL Redis 6 +).
Disable dangerous командалар Redis ('CONFIG', 'FLUSHALL', 'KEYS') ACL арқылы.
Memcached үшін - көпшілік интерфейстерін тыңдамаңыз, '-U 0' (UDP-сіз), тек жеке желілер.
PII сақталмайды; қажет болса - бағдарлама деңгейінде қысқа TTL + шифрлау.

14) Бақылау және қызмет көрсету

• Hit ratio/Miss ratio (namespace/бағыт бойынша).
• Latency p95/p99 командасы 'GET/SET/MGET', timeouts.
• Evictions и OOM errors.
• Replication lag (Redis), cluster state, migrate/rehash events.
• Трафик/байт бойынша Top-N keys (сэмплинг).
• Логтар: баяу командалар ('slowlog'), желі қателері.
• Дашбордтар: жалпы (CPU/RAM/connections), командалар, кластер слоттары, sentinels, Prometheus-экспорттаушылар арқылы өткізу.

15) Конфигалар және өрістету - мысалдар

15. 1 Redis Sentinel (үзік)

port 6379 protected-mode yes appendonly yes appendfsync everysec maxmemory-policy allkeys-lfu

sentinel monitor m1 10. 0. 0. 11 6379 2 sentinel auth-pass m1 sentinel down-after-milliseconds m1 5000 sentinel failover-timeout m1 60000

15. 2 Redis Cluster (helm values, оңайлатылған)

yaml cluster:
enabled: true nodes: 6  # 3 masters + 3 replicas persistence:
size: 100Gi resources:
requests: { cpu: "500m", memory: "2Gi" }

15. 3 Memcached (deployment)

yaml containers:
- image: memcached:1. 6 args: ["-m", "32768", "-I", "2m", "-v", "-t", "8", "-o", "modern"]
ports: [{ containerPort: 11211 }]

15. 4 NGINX ретінде read-through прокси (API контуры)

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:100m max_size=10g inactive=10m;
map $request_uri $cache_key { default "api:$request_uri"; }
location /api/ {
proxy_cache api;
proxy_cache_valid 200 1m;
proxy_cache_use_stale updating error timeout http_500 http_502 http_503 http_504;
proxy_cache_lock on;      # singleflight на уровне NGINX proxy_cache_key $cache_key;
proxy_pass http://backend;
}

16) Тестілеу және гейттер

Жүктеме профильдері «суық/жылы/ыстық кеш».
Қателіктерді инъекциялау (purge жаппай) - origin «қайта оқытуға» төзуі тиіс.
Алерталар: hit-ratio күрт құлдырауы, miss latency өсуі, evictions көшкіні, timeouts өсуі.

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

«Ақиқатты» Redis бағдарламасында AOF/RDB-сіз және резервтеусіз сақтау.
TTL = 0 (мерзімсіз) құбылмалы деректер үшін → мәңгілік тұрақсыздық.
Тораптағы жаппай 'KEYS'.
Jitter/soft-TTL → синхронды ағымдар мен дауылдың болмауы.
Шардарлаусыз/репликасыз барлық командаларға бір инстанция.
Атомарлық/скрипттерді қажет ететін тапсырмалар үшін Memcached бағдарламасын пайдалану.

18) Енгізу чек-парағы (0-45 күн)

0-10 күн

Үлгіні таңдау (cache-aside + L1/L2), кілттерді, TTL, неймспейстерді сипаттау.
jitter/soft-TTL, singleflight; базалық алерттар/дашбордтар.
Redis үшін - ACL, protected-mode, slowlog, maxmemory-policy баптау.

11-25 күн

Шардталуға (Redis Cluster немесе клиенттік хеш), репликаға өту.
pub/sub немесе неймспейс нұсқасы арқылы мүгедектік; DB outbox.
Кешті «қайта оқытудың» жүктеме тестілері; limiting origin.

26-45 күн

Автоөнеркәсіп/канарейка TTL, релизге дейін жылыту.
write-behind/фондық қайта іріктеу үшін Streams.
hit-ratio, топ-кілттер, жад құны бойынша апта сайынғы есептер.

19) Жетілу метрикасы

Hit-ratio L2 ≥ 80% (маршруттар/неймспейстер бойынша статистика).
P95 GET <2-3 ms (in-DC), қателіктер <SLO origin.
Жаппай мүгедектік кезінде 0 дауыл (тесттермен дәлелденген).
Неймспейстерді автоматты түрде мүгедектендіру және нұсқалау.
Шардалау/репликациялау 1 тораптың бұзылуын елеулі тозусыз жабады.

20) Қорытынды

Кештің күшті архитектурасы - бұл кілттер мен TTL тәртібі, дауылдан қорғау, дұрыс шардалау және болжамды ығыстыру. Redis бай семантика, персистенттілік және атомарлық береді; Memcached - максималды қарапайымдылық пен жылдамдық. Байқауды, оқиғалар бойынша мүгедектікті, L1 + L2 қосыңыз және кеш кездейсоқ құлдыраулар мен «мистикалық» жүктемелердің көзі емес, платформаның үдеткіші болады.