Redis 7+ Patterns

Hash est préférable à plusieurs Strings quand les champs sont accédés ensemble.

List (queue / stack)

LPUSH queue:jobs "job1"
RPOP queue:jobs
LLEN queue:jobs

Utiliser pour les queues simples (pour du vrai message queueing, préférer Streams).

Set (membership)

SADD tags:post1 "redis" "nosql" "cache"
SISMEMBER tags:post1 "redis"
SMEMBERS tags:post1
SINTER tags:post1 tags:post2

Sorted set (leaderboard)

ZADD leaderboard 1000 "player1" 850 "player2" 1200 "player3"
ZRANGE leaderboard 0 -1 WITHSCORES
ZRANGEBYSCORE leaderboard 500 1500
ZREVRANK leaderboard "player1"

Stream (event log)

XADD events * userId 123 type login
XREAD COUNT 10 STREAMS events 0
XGROUP CREATE events processors 0
XREADGROUP GROUP processors worker1 COUNT 1 STREAMS events >
XACK events processors <message-id>

Streams = message queue persistante avec consumer groups (alternative à Kafka/RabbitMQ pour les use cases moyens).

2. Caching patterns

Cache-aside (le plus commun)

async function getUser(id: string) {
  const cached = await redis.get(`user:${id}`)
  if (cached) return JSON.parse(cached)

  const user = await db.users.findById(id)
  if (user) {
    await redis.setex(`user:${id}`, 3600, JSON.stringify(user))
  }
  return user
}

// Invalidation
async function updateUser(id: string, data: any) {
  await db.users.update(id, data)
  await redis.del(`user:${id}`)
}

Write-through

async function updateUser(id: string, data: any) {
  const user = await db.users.update(id, data)
  await redis.setex(`user:${id}`, 3600, JSON.stringify(user))
  return user
}

Read-through

DB wrapper qui interroge Redis en premier, tombe sur la DB si miss, puis met en cache automatiquement.

TTL strategies

• Short TTL (1-60s) — données volatiles (stock, prix temps-réel)
• Medium TTL (5-60 min) — données semi-statiques (profils, articles)
• Long TTL (1-24h) — données quasi-statiques (config, taxonomies)
• No TTL — sessions actives (supprimées à logout), leaderboards

3. Rate limiting

Fixed window

async function rateLimit(userId: string, limit: number, windowSec: number) {
  const key = `rate:${userId}:${Math.floor(Date.now() / 1000 / windowSec)}`
  const count = await redis.incr(key)
  if (count === 1) await redis.expire(key, windowSec)
  if (count > limit) throw new Error('Rate limit exceeded')
}

Simple mais burst possible à la frontière de fenêtre.

Sliding window

async function slidingRateLimit(userId: string, limit: number, windowMs: number) {
  const key = `rate:${userId}`
  const now = Date.now()
  const windowStart = now - windowMs

  const pipeline = redis.pipeline()
  pipeline.zremrangebyscore(key, 0, windowStart)
  pipeline.zadd(key, now, `${now}-${Math.random()}`)
  pipeline.zcard(key)
  pipeline.expire(key, Math.ceil(windowMs / 1000))
  const results = await pipeline.exec()

  const count = results[2][1] as number
  if (count > limit) throw new Error('Rate limit exceeded')
}

Plus précis mais plus coûteux en mémoire.

Token bucket

Pour du rate limiting très précis, utiliser un script Lua atomique (scriptable côté Redis via EVAL). Voir docs officielles Redis — les scripts Lua sont exécutés atomiquement par Redis.

4. Distributed locks

Simple lock (SETNX + expiry)

async function withLock<T>(key: string, ttlSec: number, fn: () => Promise<T>): Promise<T> {
  const lockKey = `lock:${key}`
  const token = crypto.randomUUID()
  const acquired = await redis.set(lockKey, token, 'NX', 'EX', ttlSec)

  if (!acquired) throw new Error('Lock not acquired')

  try {
    return await fn()
  } finally {
    // Release only if we still hold the lock (token match)
    const releaseScript = `
      if redis.call("get", KEYS[1]) == ARGV[1] then
        return redis.call("del", KEYS[1])
      else
        return 0
      end
    `
    await redis.eval(releaseScript, 1, lockKey, token)
  }
}

// Usage
await withLock('user:123:balance', 30, async () => {
  const balance = await getBalance(123)
  await updateBalance(123, balance - 100)
})

Redlock (pour multi-instance)

Pour un lock distribué sur plusieurs instances Redis (high-availability), utiliser la library redlock qui implémente l'algorithme Redlock. Martin Kleppmann a critiqué cet algo — pour les cas vraiment critiques, utiliser un lock système (Postgres advisory locks, ZooKeeper).

5. Pub/Sub

// Publisher
await redis.publish('events:user-created', JSON.stringify({ userId: 123 }))

// Subscriber (requires a separate connection)
const sub = new Redis()
await sub.subscribe('events:user-created')
sub.on('message', (channel, message) => {
  const event = JSON.parse(message)
  // handle
})

Limites :

• Fire-and-forget — pas de persistance, message perdu si subscriber offline
• Pas de replay
• Pour du messaging fiable → Streams ou RabbitMQ / Kafka

6. Streams (message queue)

// Producer
await redis.xadd('events', '*', 'type', 'order.created', 'orderId', '123')

// Consumer group (une seule fois)
await redis.xgroup('CREATE', 'events', 'order-processors', '0', 'MKSTREAM')

// Consumer
while (true) {
  const messages = await redis.xreadgroup(
    'GROUP', 'order-processors', 'worker1',
    'COUNT', '10',
    'BLOCK', '5000',
    'STREAMS', 'events', '>'
  )
  if (!messages) continue

  for (const [stream, entries] of messages) {
    for (const [id, fields] of entries) {
      try {
        await processEvent(fields)
        await redis.xack('events', 'order-processors', id)
      } catch (err) {
        // Will be reclaimed by another consumer after idle timeout
      }
    }
  }
}

Streams = meilleure alternative à LPUSH/RPOP pour du real messaging (persistance, consumer groups, replay).

7. Persistence

RDB (Redis Database Backup)

Snapshots binaires à intervalles réguliers.

save 900 1       # 1+ change, every 15min
save 300 10      # 10+ changes, every 5min
save 60 10000    # 10000+ changes, every 1min

• Rapide à recharger
• Point-in-time recovery possible avec plusieurs snapshots
• Perte de data entre snapshots si crash

AOF (Append Only File)

Log de toutes les write operations.

appendonly yes
appendfsync everysec

• Durability meilleure (perte max = 1s)
• Reload plus lent
• Fichier plus gros que RDB

Recommandation prod

Activer RDB + AOF simultanément. En cas de restart, Redis utilise AOF (plus récent).

8. HA (Sentinel) vs Cluster

Sentinel

1 master + N replicas. Sentinel monitore et promeut un replica en cas de failover.

• Failover automatique
• Lecture depuis les replicas
• Limite : mémoire du master (pas de sharding)

Cluster

Partitionne les données sur plusieurs nodes (16384 hash slots).

• Sharding horizontal
• Chaque node master + replicas
• Complexity : client doit supporter le protocole cluster
• Pas de transactions multi-key sur des keys de slots différents

Recommandation

• Single instance + backups → projets petits (dev, staging, ~1GB data)
• Sentinel → production moyenne (1-50 GB data, besoin HA mais pas de sharding)
• Cluster → production large (> 50 GB, besoin sharding)

9. Clients Node.js

ioredis (recommandé)

npm install ioredis

import Redis from 'ioredis'

const redis = new Redis({
  host: process.env.REDIS_HOST,
  port: 6379,
  password: process.env.REDIS_PASSWORD,
  maxRetriesPerRequest: 3,
  enableReadyCheck: true,
  lazyConnect: false,
})

// Cluster
const cluster = new Redis.Cluster([
  { host: 'node1', port: 6379 },
  { host: 'node2', port: 6379 },
])

node-redis (officiel)

import { createClient } from 'redis'

const client = createClient({ url: process.env.REDIS_URL })
await client.connect()

10. Python client

pip install redis

import redis

r = redis.Redis(
    host='localhost',
    port=6379,
    db=0,
    decode_responses=True,
)

r.set('key', 'value')
value = r.get('key')

# Async
from redis import asyncio as aioredis

async def main():
    r = aioredis.from_url("redis://localhost")
    await r.set("key", "value")
    value = await r.get("key")
    await r.close()

Anti-patterns

1. KEYS * en prod → O(N), bloque Redis, utiliser SCAN
2. Single key > 100 MB → OOM risk, split en multiples keys
3. Redis comme DB primaire sans persistance → perte de data au restart
4. Session sans TTL → memory leak
5. Pub/Sub pour du critical messaging → fire-and-forget, use Streams
6. FLUSHDB en prod → data loss total
7. SET sans EX sur du cache → perte de TTL, memory leak
8. Lock sans expiry → deadlock si le worker crash
9. Cluster avec transactions multi-key sur slots différents → CROSSSLOT error
10. RDB en cloud-hosted sans persistence disk → data loss

Checklist prod

• Persistence activée (RDB + AOF)
• Password auth + TLS
• maxmemory-policy configuré (allkeys-lru pour cache, noeviction pour queue)
• Sentinel ou Cluster selon besoin HA
• Backups off-server
• Monitoring — INFO metrics via Prometheus redis_exporter
• Slow log — CONFIG SET slowlog-log-slower-than 10000
• Key TTL partout où applicable
• Naming convention <service>:<entity>:<id>:<field>
• Pipelines pour les opérations bulk
• Connection pool correctement sized

Quand déléguer

• Données relationnelles → postgres-patterns
• Documents JSON → mongodb-patterns
• Real-time WebSocket → skill realtime-websocket (dans ce plugin, à venir)
• Message queue Kafka → pas dans ce plugin, considérer Temporal ou BullMQ
• Cache CDN → deploy-cloudflare / deploy-vercel

Ressources

• https://redis.io/docs/
• https://redis.io/docs/data-types/
• https://redis.io/docs/management/persistence/
• https://redis.io/docs/management/scaling/
• https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html (Redlock critique)