GH GambleHub

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

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

1) Качан жана эмне үчүн кэш

Максаттары: жашыруун азайтуу, DD/PSP/тышкы API түшүрүп, жана чокуларын жумшартат.
Кэш катмарлары көбүнчө көп баскычтуу: in-process (L1) → service-level (Redis/Memcached L2) → edge/CDN. Ички кэш "ысык" окууларды тездетет, L2 - кызматтар үчүн жалпы, edge - коомдук мазмун үчүн.

2) Redis vs Memcached - кыскача

КритерийRedisMemcached
Маалыматтардын түрлөрүЛиниялар, хэштер, тизмелер, көптүктөр, zset, битмаптар, HyperLogLog, Streams, Bloom/CF (модулдары аркылуу)Ачкыч мааниси
ТуруктууAOF/RDB, no-fsync-loss орнотуудаЖок
КластерRedis Cluster (charding, failover )/SentinelКардар Шард, жок Native failover
Транзакциялар/скрипттерMULTI/EXEC, EVAL (Lua), атомдук ишЖок
TTL/evictionКылдат саясат орнотууБазалык
Жашыруун/эсБир аз көбүрөөк overheadАбдан жеңил, алдын ала

Эреже: Эгер татаал берилиштер структуралары, туруктуу, pub/sub/агымдар/скрипт керек болсо - Redis алып. Эгерде супер жөнөкөй, тез, арзан KV кэш катмары жок durability - Memcached.

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

3. 1 Cache-aside (lazy)

Тиркеме кэш → ката → DD from окуп → TTL менен кэш салып.

Жөнөкөй TTL контролдоо, кэш көз карандысыздыгы. − каталар менен "бороон" болушу мүмкүн.

3. 2 Read-through

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

Борборлоштурулган логика. − Татаал инфраструктура.

3. 3 Write-through / Write-behind

Write-through: жазуу биринчи кэш, андан кийин DD.
Write-behind: кезекке жазуу, БДдагы асинхрондук флаш (мүмкүн болуучу жоготуу - журнал керек).

3. 4 Two-tier (L1+L2)

L1 (in-process) менен кыска TTL жана жумшак TTL, L2 (Redis/Memcached) - "кэш чындык". pub/sub аркылуу майып.

4) TTL, бороон-чапкын жана туруктуулук

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

Dogpile (thundering herd): каталарды коргоо:
  • 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) Hot Keys жана Charding

Hot-keys: hit/miss/byte боюнча top-N мониторинг. Өтө ысык ачкычтар үчүн:
  • Replicated read pattern: бир нече shard-ачкычтар 'hot: k: 1.. N' маанисин кайталап, окуп жатканда туш келди тандап.
  • Local L1: майыптыкка жазылуу менен жараяндын эсинде сактаңыз.
Шардировка:
  • Redis Cluster - жергиликтүү (16384 hash-slot).
  • 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 MB, slab тюнинг).
Ашыкча эс алдын ала болушу керек: активдүү жолдо 'noeviction' эмес.

Redis


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) Майыптык жана макулдашуу

Окуя боюнча: DD өзгөртүлгөндө 'pub/sub' окуясын 'invalidate: {ns}: {id}' → жазылуучулар ачкычтарды өчүрүшөт.
Таймер боюнча: тез-тез өзгөрүп жаткан маалыматтар үчүн кыска TTL.
Версиялоо: кара 'ns:' ачкычтар.
Outbox: майыптыгы жеткирүү кепилдиги (log/Топик, Ретраи окуя).
Кэш менен операциялардын ыктуулугу: 'SETXX/SETNX', версиялары ('etag') жана инкремент үчүн хэш талааларын колдонуңуз.

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

10. 1 Redis

Sentinel: автоматтык failover master-replica (stateful IP/аты-жөнү).
Cluster: charding + auto failover; кардарлар 'MOVED/ASK' редакторлорун колдошу керек.
AOF/RDB: Кэш үчүн, адатта, 'appendfsync everysec' туруктуу (таза кэш катары) болушу мүмкүн.

10. 2 Memcached

Кутудан репликация жок. Ишенимдүүлүк - көп дарбазалуу шард + кайталоо 'n' (client-side) аркылуу.
Нода кулаганда - каталардын көбөйүшү жана кэштин "кайра даярдалышы".

10. 3 K8s жана тармактык аспектилери

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

11) бүтүмдөр, скрипт жана атомдук (Redis)

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

Мисал rate-limit (token bucket, жөнөкөйлөштүрүлгөн):
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/күйөрмандар үчүн ыңгайлуу.
Lists ('BRPOP'): жөнөкөй кезек.
Редисти "бардык нерсенин бир дөңгөлөгү" катары колдонбоңуз - бул кэш/тез дөңгөлөк, Кафка эмес.

13) Коопсуздук жана жетүү

Тармактарды изоляциялоо/VPC, mTLS ingress деңгээл, ACL/сырсөздөр ('requirepass '/ACL Redis 6 +).
Redis Disable dangerous команда ('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'), тармак каталар.
  • Dashbord: жалпы (CPU/RAM/байланыштар), команда, кластердик уячалар, sentinels, Prometheus экспорттоочулар аркылуу өтүп.

15) Конфиги жана жайгаштыруу - мисалдар

15. 1 Redis Sentinel (үзүндү)


port 6379 protected-mode yes appendonly yes appendfsync everysec maxmemory-policy allkeys-lfu
`sentinel. conf`:

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) Сыноо жана гейтс

Жүктөө профилдери "муздак/жылуу/ысык кэш".
Injection каталар (purge массалык) - origin "кайра" туруштук бериши керек.
Alerts: hit-ratio кескин төмөндөшү, miss latency өсүшү, көчкү evictions, timeouts өсүшү.

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

AOF/RDB жана камдык жок Redis менен "чындык" сактоо.
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 же неймспейс чыгаруу аркылуу майып; DD outbox.
Жүктөө тесттер "кайра" кэш; limiting origin.

26-45 күн

Auto промо/канарейка TTL, бошотуу алдында жылытуу.
Streams үчүн write-behind/арткы кайра.
hit-ratio, жогорку ачкычтар, эс наркы боюнча жумалык отчеттор.

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

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

20) Корутунду

Күчтүү кэш архитектурасы - бул ачкычтардын жана TTLдин дисциплинасы, бороон-чапкындан коргоо, туура шардана кылуу жана алдын ала айтуу. Redis бай семантика, туруктуу жана атомдук берет; Memcached - максималдуу жөнөкөйлүгү жана ылдамдыгы. Байкоо кошуу, окуялар боюнча майыптык, L1 + L2, жана кэш кокусунан кулап жана "мистикалык" каталар булагы эмес, платформа тездетүүчү болуп калат.

Contact

Биз менен байланышыңыз

Кандай гана суроо же колдоо керек болбосун — бизге кайрылыңыз.Биз дайым жардам берүүгө даярбыз!

Telegram
@Gamble_GC
Интеграцияны баштоо

Email — милдеттүү. Telegram же WhatsApp — каалооңузга жараша.

Атыңыз милдеттүү эмес
Email милдеттүү эмес
Тема милдеттүү эмес
Билдирүү милдеттүү эмес
Telegram милдеттүү эмес
@
Эгер Telegram көрсөтсөңүз — Emailден тышкары ошол жактан да жооп беребиз.
WhatsApp милдеттүү эмес
Формат: өлкөнүн коду жана номер (мисалы, +996XXXXXXXXX).

Түшүрүү баскычын басуу менен сиз маалыматтарыңыздын иштетилишине макул болосуз.