Tecnología e Infraestructura → Redis: soluciones in-memory

Redis: soluciones in-memory

1) Donde Redis es apropiado

• Caché (read-through/aside, TTL, SWR) y sesiones.
• Contadores y cuotas: rate limiting, antifraude, límites de campaña.
• Leadboards/rankings (ZSet), recomendaciones «top N».
• Colas/bus de eventos (Streams/PubSub), outbox/inbox, retraídas.
• Idempotencia (claves con TTL), de-dup webhooks.
• Geo (buscar los puntos más cercanos), Bitmap (banderas, DAU).
• Alias/tokens y cachés de autorización de vida corta.

2) Estructuras de datos y cuándo aplicarlos

Cadena: valores/contadores ('INCRBY'), llaves idempotentes.
Hash: agregados de perfiles/confecciones, almacenamiento de objetos «ligeros».
Lista: colas simples (pero sin replay/offset-semántica).
Set: elementos únicos, deduplicación.
ZSet: ordenar por corcho (tablas de liderazgo, calendario TTL - eventos «diferidos»).
Stream: colas sostenibles con grupos de consumidores, 'XREADGROUP '/replay - para webhooks, CDC, retraídas.
Geo: 'GEOADD/GEORADIUS' son los puntos/merchantes más cercanos.
Bitmap/Bitfield: series de banderas (Logins on Day, DAU/WAU).
HyperLogLog: aproximado único (UU) barato de memoria.
Bloom/Cuckoo (módulos): verificaciones rápidas de disponibilidad, reducen el «MISS» a la fuente.

• RedisJSON (documentos JSON), RediSearch (indexación/búsqueda), RedisBloom (estructuras probabilísticas), TimeSeries (métricas/agregaciones).

3) Claves, TTL y políticas de memoria

tenant:{t}:domain:{d}:{entity}:{id}:v{schema}    region={R}    currency={C}    lang={L}

Versionar ('vN'), incluir sólo medidas significativas (región/moneda/idioma/tenant).
Aísle los espacios de claves per-tenant.

• Use la matriz TTL (sec/min/hora), agregue el jitter (± 10-20%) para evitar el stampede.
• Para las claves calientes, refresh-ahead y single-flight (un líder actualiza).

• 'allkeys-lru/lfu' es un caché común sin dependencia TTL.
• 'volatile-lru/lfu' - sólo claves con TTL.
• 'noeviction' es un error de escritura en el desbordamiento (más seguro para colas/contadores críticos).
• Seleccione bajo el script y siempre supervise 'evicted _ keys'.

4) Transacciones, pipelines y scripts

Pipelines: reducir RTT, agrupar 10-100 comandos.
Transacciones (MULTI/EXEC): no aíslan las lecturas, sino que ejecutan atomicamente el paquete.
Encierro optimístico: 'WATCH key' → validación → 'MULTI/EXEC'.
Secuencias de comandos lua: lógica atómica en el lado del servidor (rate limit, locks, componite-operations).

5) Colas y neumáticos: List vs Stream

List + 'BRPOP' es simple, pero no hay grupos de consumo, offset/replay, débil resistencia a las caídas.
Stream: 'XADD → XREADGROUP → XACK', retry-deadletter (sin saber en N minutos), lote por clave. Recomendado para webhooks PSP/KYC, pagos diferidos/notificaciones.

Colas prioritarias: varios streams por prioridades, los consumidores «chupan» de lo alto en primer lugar.
Tareas pendientes: ZSet donde score = timestamp; periódico 'ZRANGEBYSCORE' ≤ ahora → transferencia a Stream.

6) Alta disponibilidad y escalabilidad

Replicación: master→replica (read-scale).
Sentinel: failover automático master 'a, detección, URI de cliente.
Redis Cluster: charding en 16384 ranuras, scale-out horizontal. Las claves que utilizan varias estructuras se envuelven en etiquetas hash '{order: 123}'.

• Para el caché/sesión - clúster/réplica, 'client-side hashing' es compatible con SDK.
• Para colas/streams: minimice las operaciones de ranura cruzada; lote las llaves del dominio.

7) Persistencia: RDB, AOF y backups

RDB (instantáneas): más rápido, más económico; el riesgo de perder los últimos segundos/minutos.
AOF (registro): menos pérdidas; modos 'everysec/always'. Compresión AOF y re-embalaje periódico.
Híbrido: RDB + AOF → recuperación rápida + pérdidas moderadas.
Backups: snapshots y copias de AOF a la bóveda de objetos; compruebe la recuperación regularmente.

Para colas críticas/idempotencia, seleccione la replicación AOF 'everysec' +.

8) Seguridad y cumplimiento

AUTH/ACL: roles per-app, prohibición de comandos «peligrosos» ('FLUSHALL', 'KEYS').
TLS por cliente-servidor y links entre nodos; egress-IP fijos.
Segmentación de la red: subredes privadas, SG/NACL; acceso sólo desde los servicios/neymspaces deseados.
Los secretos no son lógicos; PAN/PII en Redis - sólo tokens/derivados.
Comandos de clave: evite 'KEYS' - use' SCAN '.

9) Observabilidad y SLO

• Latency (P95/P99), `instantaneous_ops_per_sec`, `connected_clients`.
• Hit ratio, evicted_keys, expired_keys.
• Memory: used, fragmentation ratio, RSS, allocator stats.
• Replication log, AOF/RDB frecuencias y dimensiones, fork time.
• Streams: PEL (pending entries list), delivery latency, retry count.

• Operaciones Redis P99 ≤ 5-10 ms.
• Evictions ≤ 1 %/hora (espacio caché).
• Stream delivery P99 ≤ 500 мс, retry rate < 2%.

10) FinOps y planificación de recursos

Memoria carretera: medir $/GB-mes RAM vs ahorro de solicitudes a origin/DB.
Incluye compresión de valores> 1-2 KB (ver CPU).
La LFU puede dar un mejor hit con menos volumen.
Para imágenes/grandes bloques - no Redis: utilice CDN + almacenamiento de objetos.

11) Patrones para iGaming/Fintech

11. 1 Nota limitada (ventana deslizante, Lua)

Idea: 'INCRBY' en la clave de la ventana + TTL; Lua comprueba atómicamente el límite y aumenta.

lua
-- KEYS[1]=key ARGV[1]=limit ARGV[2]=ttlSec ARGV[3]=inc local cur = redis. call('INCRBY', KEYS[1], ARGV[3])
if cur == tonumber(ARGV[3]) then redis. call('EXPIRE', KEYS[1], ARGV[2]) end if cur > tonumber(ARGV[1]) then return {0, cur} else return {1, cur} end

11. 2 Idempotencia de las solicitudes

Clave 'idemp: {request _ id}' con TTL 24h, el valor es resultado/estado. Antes de realizar la operación - Comprobamos si existe.

11. 3 Tablas de liderazgo

`ZINCRBY leaderboard:game:{g} score user:{u}` → `ZREVRANGE... WITHSCORES`.
Para el N superior por región/tenante, ZSet o prefijos individuales.

11. 4 Cola de webhooks PSP

'XADD psp: webhooks...' → del grupo de consumidores 'XGROUP CREATE psp: webhooks g1 $'.
Retratos de mensajes «dependientes» a través del análisis PEL ('XPENDING' → 'XCLAIM').

11. 5 Pagos diferidos

ZSet 'payout: due' (score = epoch) → worker transfiere periódicamente los elementos terminados a Stream 'payout: exec' con deduplicación.

11. 6 Contadores antifraude

Combinación de 'PFADD' (único) +' INCR '(intensidad) + etiquetas geo/ASN; desencadenantes para la verificación manual.

12) Trabajar con memoria y rendimiento

Grupos de conexiones de clientes; reduzca el RTT (keep-alive).
Prefiera las pipelines al paquete de comandos.
Seguir las grandes llaves ('MEMORY USAGE', 'SCAN') - triturar mejor los objetos.
Hash con un pequeño número de campos es más económico que muchas claves individuales.
Habilita io-threads (read-heavy) si el profit está confirmado por pruebas.
Evite los frecuentes 'FLUSHDB/ALL' en venta; controle a través de prefijos y 'UNLINK' para su eliminación segura.

13) Multi-tenant y aislamiento

Clústeres/instancias individuales o logical DB per-tenant (si la carga es pequeña).
Cuotas de clave/memoria separadas por LCA.
Prefijos en claves y métricas por namespace.

14) Bloqueo y consistencia

SET key val NX PX = ttl es un simple mutex.
Redlock: use suavemente; para las transacciones críticas distribuidas, es mejor confiar en la «fuente de la verdad» (DB/ledger) y las operaciones idempotentes.
Prefiera operaciones atómicas y Lua en lugar de bloqueos «largos».

15) Anti-patrones

Almacenamiento de grandes blobs/imágenes: sobrecarga de RAM y redes.
Invariantes financieros (balance) sólo en Redis.
'KEYS' y' escanear el mundo 'en venta.
No hay TTL/jitter - dogpile en la expiración.
La política 'allkeys-' en colas críticas → pérdida de datos a presiones.
Mezclar colas, kash y sesiones en una sola instancia sin cuotas ni prioridades.
Scripts de lua que funcionan con las claves de diferentes ranuras en Cluster.

16) Lista de verificación de implementación

1. Definir roles: caché/sesiones, colas/streams, contadores/límites - dividir por instancias/clústeres.
2. Seleccione maxmemory-policy en la tarea; establezca límites y supervise las evictions.
3. Llaves de Neyming, versiones de circuitos, matriz TTL + jitter; un solo vuelo para las teclas principales.
4. Para las colas - Streams (grupos, retraídas, DLQ), para las pospuestas - ZSet + transferencia.
5. HA: replicación + Sentinel o Redis Cluster; compruebe el failover del cliente.
6. Persistencia: RDB/AOF bajo escenario; backups regulares y prueba de recuperación.
7. Seguridad: ACL, TLS, redes privadas, prohibición de comandos peligrosos.
8. Observabilidad: latency, ops/sec, memory, evictions, replication lag, stream PEL.
9. FinOps: perfiles de memoria, claves grandes, compresión, LFU; evitar Redis para grandes bloques.
10. Documentación de patrones (rate-limit, idempotent, leadboards) y pruebas de carga.

Resultado

Redis es un «cuchillo suizo multifuncional» de velocidad: caché, colas, contadores, tablas de liderazgo, geo y estructuras probabilísticas. Su fuerza está en la correcta selección de las estructuras de datos, la disciplina TTL/discapacidad, la atomicidad de las operaciones, así como en la reflexiva NA/persistencia y observabilidad. Use Redis donde los milisegundos y RPS altos son importantes, mientras deja invariantes críticos (dinero, contabilidad) a la «fuente de la verdad» - así la plataforma seguirá siendo rápida y confiable.