Arquitetura de cachê: Redis, Memcached

Arquitetura de cachê: Redis, Memcached

1) Quando e porquê

Os objetivos são reduzir a latência, descarregar o BB/PSP/API externa e suavizar os picos.
As camadas de cajel são muitas vezes de vários níveis: in-processo (L1) → service-level (Redis/Memcached L2) → edge/CDN. O kesh interno acelera a leitura «quente», o L2 é comum para serviços e o edge para conteúdo público.

2) Redis vs Memcached - breve

Regra: se você precisar de complexas estruturas de dados, personalidade, pub/sub/striptease/script - pegue Redis. Se super simples, rápido, barato KV-kesh sem durability - Memcached.

3) Modelos de cachê

3. 1 Cache-aside (lazy)

O aplicativo é lido a partir de uma falha → → lido a partir de um banco de dados → colocado em uma caixa com TTL.

Controle simples da TTL, independente do caju.

3. 2 Read-through

O cliente/proxy ele mesmo puxa para fora do origin ao falhar e põe no caju.

Uma lógica centralizada.

3. 3 Write-through / Write-behind

Write-through: gravar primeiro em kesh, depois em BB.
Write-behind: gravação na fila, flu asinhrônico na base de dados (perda potencial no colapso - necessário registro).

3. 4 Two-tier (L1+L2)

L1 (in-processo) com TTL curto e soft TTL, L2 (Redis/Memcached) - «verdade do cajá». Deficiência via pub/sub.

4) TTL, tempestades e consistência

TTL: Coloque perto da taxa de alteração de dados. Para as chaves quentes, use a randomização TTL (jitter): 'ttl = base searand (0.. base0. 1) '- retira os vencimentos sincronizados.

• Singleflight: apenas um processo sobrecarrega o valor (consulte o exemplo Lua).
• Soft-TTL + background refresh: Depois de 'soft _ ttl', dê um fundo obsoleto (stale) e atualize.
• Semaphore/lock: `SET key:lock value NX PX=2000`.
• Near-state: 'stale-while-revalidate' para as respostas API (consulte secção 8).

5) Chaves, neymspace, serialização

5. 1 Denominação de chaves

Gabarito: ' Exemplos:

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

Adicione uma versão do esquema (': v2') para facilitar a deficiência em massa.

5. 2 Neymspace através da «versão do espaço»

Mantenha a chave 'ns: catalog = 17'. Chaves reais: 'catalog: 17: product: 1001'. Para deficiência global do catálogo, basta incorporar 'ns: catalog'.

5. 3 Serialização/Compressão

O JSON é confortável, mas pesado. Use o MessagePack/CBOR.
Inclua a compressão (LZ4/ZSTD) para payload maiores (> 1-2 KB). Na Redis, do lado do cliente.

6) Chaves quentes e churrasqueira

• Replicated read pattern: Duplique o valor em várias chaves shard 'hot: k: 1.. N', selecione o valor aleatório durante a leitura.
• Local L1: mantenha a memória do processo com a subscrição de deficiência.

• Redis Cluster - nativo (16384 hash slots).
• Memcached é um hash de consistência do cliente.
• O hash-tag em Redis 'a.... a.' capta a slot para o conjunto de chaves:' user: se é que ele está na mesma lista.

7) Políticas de exclusão e tamanho

Redis `maxmemory-policy`: `allkeys-lru`, `volatile-lru`, `allkeys-lfu`, `noeviction` и т. д. Para kesha, normalmente 'allkeys-lru '/' allkeys-lfu'.
Memcached — LRU на item-slab.
Tamanho da chave e valor: siga o max item size (Memcached padrão de 1 MB, sintonizar slab).
Excesso de memória deve degradar previsivelmente, não 'noevition' no caminho ativo.

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

8) Protecção contra tempestades - código

8. 1 Redis Lua singleflight (pseudo)

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 cachê-aside (simplificado)

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) Deficiência e coerência

Por evento: quando você editar o banco de dados, publique 'pub/sub' evento 'invalidate: se você estiver alterado para o banco de dados, os assinantes removem as chaves.
Um TTL curto para dados que mudam frequentemente.
Versioning: Consulte «ns:» chaves.
Outbox: garantia de entrega de deficiência (evento logic/topic, retrai).
Use 'SETXX/SETNX', versões 'etag' e 'hash' para a incorporação.

10) Replicação, cluster, failover

10. 1 Redis

Sentinel: failover automática master-replica (steitFUL IP/nome).
Cluster: charding + failover automático; os clientes devem manter os redirets 'MOVED/ASK'.
AOF/RDB: Para kesha normalmente 'appendfsync everysec', pode-se não ter personalidade (como puro kesh).

10. 2 Memcached

Não há replicação da caixa. Confiabilidade através de um shard de vários servidores + repetição de 'n' (cliente-side).
Quando o buraco cai, o crescimento das faltas e o «repaginamento» do cajá.

10. 3 K8s e aspectos de rede

Redis/Memcached não gosta de reencontrar pod' ov frequentemente; use StatefulSet + antípodas AZ, PVC/POD IP fixo.
Ponham PodDisruptionBudget e TopologySpreadConstraints.

11) Transações, script e atômica (Redis)

INCR/DECR, HINCRBY - Contadores, quotas, rate-limits (apenas leve em conta persist).
MULTI/EXEC é um pacote de comandos atômicos.
Lua (EVAL) - read-modify-write sem corridas.
Pipeline: reduz o RPT (especialmente no hop de rede).

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) Filas, pub/sub e Streams (Redis)

Pub/Sub: deficiência, sinais. Sem preservação, só ouvintes online.
Streams: filas de eventos de confirmação (ACK), grupos de consumidores, retais - conveniente para write-behind/fan-outs.
Lists ('BRPOP'): filas simples.
Não use Redis como «um único pneu tudo» sem bacape - é um pneu de kesh/rápido, não Kafka.

13) Segurança e acesso

Isolar as redes/VPC, mTLS no nível ingress, LCA/senhas ('requipass '/LCA no Redis 6 +).
Os comandos Disable Drogous em Redis ('CONFIG', 'FLUSHALL', 'KEYS') através da LCA.
Para Memcached - não ouvir interfaces públicas, '-U 0' (sem UDP), apenas redes privadas.
PII não armazenar; se necessário, criptografia TTL + curta ao nível do aplicativo.

14) Observabilidade e manutenção

• Hit ratio/Miss ratio (por namespace/rota).
• Latency p95/p99 comandos 'GET/SET/MGET', timeouts.
• Evictions и OOM errors.
• Replication lag (Redis), cluster state, migrate/rehash events.
• Top-N keys de tráfego/bytes (sampling).
• Logi: comandos lentos ('slowlog'), erros de rede.
• Dashboards: compartilhamento (CPU/RAM/connections), comandos, slots do cluster, sentinels, passando por Prometheus exportadores.

15) Configs e implantação - exemplos

15. 1 Redis Sentinel (fatia)

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, simplificado)

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 como read-through proxy (caminho 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) Testes e gates

Perfis de carga «fria/quente/quente kesh».
Injeção de faltas (purge em massa) - origin deve suportar «reexaminação».
Alerts: queda acentuada hit-ratio, crescimento de miss latency, avalanche de evictions, crescimento timeouts.

17) Anti-pattern

Armazenar «verdade» no Redis sem AOF/RDB e sem reserva.
TTL = 0 (indefinidamente) para dados voláteis → eterna não-conservação.
«KEYS» em massa.
Falta de jitter/soft-TTL → vencimentos sincronizados e tempestade.
Uma única instância para todos os comandos sem charding/réplica.
Usar o Memcached para tarefas que requerem atômica/script.

18) Folha de cheque de implementação (0-45 dias)

0-10 dias

Selecionar um modelo (cachê-aside + L1/L2), descrever chaves, TTL, neimspace.
Incluir jitter/soft-TTL, singleflight; alertas básicos/dashboards.
Para Redis - Personalizar ACL, protected-modo, slowlog, maxmemory-policy.

11 a 25 dias

Ir para charding (Redis Cluster ou cliente hash), réplicas.
Deficiência via pub/sub ou versão neimspace; outbox na base de dados.
Testes de carga de «reaprendimento» do cajá; limiting origin.

26-45 dias

TTL automático/canário, aquecido antes do lançamento.
Streams para cruzamentos de fundo write-behind.
Relatórios semanais de hit-ratio, top chaves, custo de memória.

19) Métricas de maturidade

Hit-ratio L2 ≥ 80% (estatísticas sobre rotas/neymspace).
P95 GET <2-3 ms (in-DC), falhas <SLO origin.
0 tempestade de deficiência em massa (comprovado por testes).
Deficiência automática e versionização de neymspace.
Charding/replicação cobre a falha de 1 nó sem degradação visível.

20) Conclusão

A forte arquitetura de kesha é uma disciplina de chaves e TTL, proteção contra tempestade, charding correto e expulsão previsível. Redis dá uma rica semântica, persistência e atômica; Memcached é o máximo de simplicidade e velocidade. Adicione observabilidade, deficiência por evento, L1 + L2, e kesh será um acelerador de plataforma, em vez de uma fonte de baixas aleatórias e bags «místicos».