Technologie et infrastructure → Redis : solutions in-memory

Redis : solutions in-memory

1) Lorsque Redis est approprié

• Kesh (read-through/aside, TTL, SWR) et sessions.
• Compteurs et quotas : rate limiting, antifrod, limites de campagne.
• Liderbords/classements (ZSet), recommandations "top N'.
• Files d'attente/bus d'événements (Streams/PubSub), outbox/inbox, retraits.
• Idempotence (clés avec TTL), de-dup webhooks.
• Geo (recherche des points les plus proches), Bitmap (drapeaux, DAU).
• Alias/tokens et caches d'autorisation à courte durée de vie.

2) Structures de données et quand les appliquer

String : valeurs/compteurs ('INCRBY'), clés idempotent.
Hash : agrégats de profils/configues, stockage d'objets « légers ».
List : files d'attente simples (mais pas de replay/offset-sémantique).
Set : éléments uniques, déduplication.
ZSet : tri par score (leaders, calendrier TTL - événements « reportés »).
Stream : files d'attente durables avec des groupes de consommateurs, 'XREADGROUP '/replay - pour webhooks, CDC, retraits.
Geo : 'GEOADD/GEORADIUS' sont les points les plus proches.
Bitmap/Bitfield : série de drapeaux (logins par jour, DAU/WAU).
HyperLogLog : approximativement unique (UU) est bon marché en mémoire.
Bloom/Cuckoo (modules) : contrôles de disponibilité rapides, abaissent « MISS » à la source.

• RedisJSON (JSON documents), RediSearch (indexation/recherche), RedisBloom (structures probabilistes), TimeSeries (métriques/agrégations).

3) Clés, TTL et politiques de mémoire

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

Versioner (« vN »), inclure uniquement les mesures significatives (région/monnaie/langue/tenant).
Isolez les espaces clés per-tenant.

• Utilisez une matrice TTL (sec/min/heure), ajoutez un jitter (± 10-20 %) pour éviter le stampede.
• Pour les clés chaudes - refresh-ahead et single-flight (un leader met à jour).

• 'allkeys-lru/lfu 'est un cache commun sans dépendance TTL.
• « volatile-lru/lfu » - seulement les clés avec TTL.
• « noevision » : défaut d'écriture en cas de débordement (plus sûr pour les files d'attente/compteurs critiques).
• Sélectionnez le script et surveillez toujours 'evicted _ keys'.

4) Transactions, pipelines et scripts

Piplines : Réduire la RTT, regrouper 10-100 commandes.
Transactions (MULTI/EXEC) : ne pas isoler les lectures, mais exécuter atomiquement le paquet.
Verrouillage optimiste : 'WATCH key' → vérification → 'MULTI/EXEC'.
Scripts lua : logique atomique côté serveur (rate limit, locks, composite-opération).

5) Files d'attente et pneus : List vs Stream

List + 'BRPOP' est simple, mais il n'y a pas de groupes de consommation, offset/replay, faible résistance aux chutes.
Stream : 'XADD → XREADGROUP → XACK', retry-deadletter (difficile en N minutes), lot par clé. Recommandé pour les webhooks PSP/KYC, paiements différés/notifications.

Files d'attente prioritaires : quelques coupes par priorité, les consommateurs « aspirent » du haut d'abord.
Tâches retardées : ZSet où score = timestamp ; « ZRANGEBYSCORE » périodique ≤ maintenant → transfert dans Stream.

6) Haute disponibilité et évolutivité

Réplication : master→replica (read-scale).
Sentinel : Automatic failover master 'a, détection, URI client.
Redis Cluster : Chardonnez-vous sur 16384 slots, scale-out horizontal. Enveloppez les clés utilisant plusieurs structures dans les balises de hachage '{order : 123}'.

• Pour le cache/sessions - cluster/réplica, 'client-side hashing' est pris en charge par le SDK.
• Pour les files d'attente/strim - minimiser les opérations de slot croisé ; Classez par clé de domaine.

7) Persévérance : RDB, AOF et backup

RDB (snapshots) : plus rapide, plus économique ; le risque de perdre les dernières secondes/minutes.
AOF (journal) : moins de pertes ; les modes « everysec/always ». Compression AOF et reconditionnement périodique.
Hybride : RDB + AOF → récupération rapide + pertes modérées.
Backups : snapshots et copies AOF dans le stockage objet ; vérifiez la récupération régulièrement.

Pour les files d'attente/idempotence critiques, choisissez AOF 'everysec' + réplication.

8) Sécurité et conformité

AUTH/ACL : rôles par application, interdiction des commandes « dangereuses » ('FLUSHALL', 'KEYS').
TLS par client-serveur et liens inter-nœuds ; egress-IP fixe.
Segmentation du réseau : sous-réseaux privés, SG/NACL ; accès uniquement à partir des bons services/neimspace.
Ne logiez pas les secrets ; PAN/PII dans Redis ne sont que des tokens/dérivés.
Commandes clés : évitez 'KEYS' - utilisez' SCAN '.

9) Observabilité et SLO

• Latency (P95/P99), `instantaneous_ops_per_sec`, `connected_clients`.
• Hit ratio, evicted_keys, expired_keys.
• Memory: used, fragmentation ratio, RSS, allocator stats.
• Replication lag, AOF/RDB fréquences et tailles, fork time.
• Streams: PEL (pending entries list), delivery latency, retry count.

• Opérations Redis P99 ≤ 5-10 ms.
• Evictions ≤ 1 %/heure (espace cache).
• Stream delivery P99 ≤ 500 мс, retry rate < 2%.

10) FinOps et planification des ressources

La mémoire est coûteuse : mesurer $/GB-mes RAM vs économiser des demandes d'origin/OBD.
Activez la compression des valeurs> 1-2 Ko (voir CPU).
LFU peut donner un meilleur hit avec moins de volume.
Pour les images/gros blobs - pas Redis : utilisez le stockage d'objets CDN +.

11) Patterns pour iGaming/fintech

11. 1 limite de taux (fenêtre coulissante, Lua)

Idée : 'INCRBY'dans la clé de fenêtre + TTL ; Lua vérifie atomiquement la limite et augmente.

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 Idempotence des demandes

La clé 'id....: {request _ id}' avec TTL 24h, la valeur est le résultat/état. Avant d'effectuer l'opération, nous vérifions la disponibilité.

11. 3 Liderboards

`ZINCRBY leaderboard:game:{g} score user:{u}` → `ZREVRANGE... WITHSCORES`.
Pour le top N par région/tenant - ZSet ou préfixes distincts.

11. 4 La file d'attente des webhooks PSP

'XADD psp : webhooks... '→ le groupe de consommateurs' XGROUP CREATE psp : webhooks g1 $ '.
Retraits de messages « accrochés » via un scan PEL ('XPENDING' → 'XCLAIM').

11. 5 Paiements différés

ZSet 'payout : due' (score = epoch) → le worker transfère périodiquement les éléments finis dans Stream 'payout : exec' avec déduplication.

11. 6 compteurs antifrod

Combinaison 'PFADD' (unique) +' INCR '(intensité) + étiquette géo/ASN ; déclencheurs pour la vérification manuelle.

12) Travailler avec la mémoire et la performance

Pools de connexions clients ; réduire le RTT (keep-alive).
Préférez les piplines à un paquet d'équipes.
Regardez les grandes clés ('MEMORY USAGE', 'SCAN') - mieux vaut écraser les objets.
Hash avec un petit nombre de champs est plus économique que de nombreuses clés individuelles.
Activez io-threads (read-heavy) si le profit est confirmé par des tests.
Éviter les « FLUSHDB/ALL » fréquents dans la vente ; contrôler via les préfixes et 'UNLINK' pour supprimer en toute sécurité.

13) Multi-tenant et isolant

Clusters/instances individuels ou logical DB per-tenant (si la charge est faible).
Quotas clés/mémoire séparés par ACL.
Préfixes dans les clés et métriques par namespace.

14) Locking et cohérence

SET key val NX PX = ttl est un simple mutex.
Redlock : utiliser avec soin ; pour les transactions critiques distribuées, il est préférable de s'appuyer sur la « source de vérité » (OBD/ledger) et les opérations idempotentes.
Préférez les opérations atomiques et Lua plutôt que les blocages « longs ».

15) Anti-modèles

Stockage de gros blobs/images - surchauffe RAM et réseaux.
Invariants financiers (bilan) uniquement dans Redis.
"KEYS'et" scan du monde "dans la vente.
Absence de TTL/jitter - dogpile à l'expiration.
La politique « allkeys- » sur les files d'attente critiques → la perte de données à la pression.
Mélange de files d'attente, de cache et de sessions en une seule instance sans quotas ni priorités.
Scripts lua fonctionnant avec des clés de slots différents dans Cluster.

16) Chèque de mise en œuvre

1. Définissez les rôles : cache/sessions, files d'attente/strimes, compteurs/limites - espacez les instances/clusters.
2. Sélectionnez maxmemory-policy sous la tâche ; fixez des limites et surveillez les événements.
3. Neuming de clés, versions de circuits, matrice TTL + jitter ; single-flight pour les clés supérieures.
4. Pour les files d'attente - Streams (groupes, rétroactions, DLQ), pour les files d'attente - ZSet + transfert.
5. HA : Réplication + Sentinelle ou Redis Cluster ; vérifier l'échec du client.
6. Persévérance : RDB/AOF pour le scénario ; backaps réguliers et test de récupération.
7. Sécurité : ACL, TLS, réseaux privés, interdiction des commandes dangereuses.
8. Observabilité : latency, ops/sec, memory, evictions, replication lag, stream PEL.
9. FinOps : profils mémoire, clés importantes, compressions, LFU ; évitez les Redis pour les gros blobs.
10. Documentation de patterns (rate-limit, idempotence, leaders) et tests de charge.

Total

Redis est un « couteau suisse multifonctionnel » de vitesse : cache, files d'attente, compteurs, leaders, géo et structures probabilistes. Sa force réside dans le bon choix des structures de données, la discipline de la TTL/invalidité, l'atomicité des opérations, ainsi que dans la persévérance et l'observation réfléchies. Utilisez Redis là où les millisecondes et le RPS élevé sont importants, tout en laissant les invariants critiques (argent, comptabilité) à la « source de la vérité » - de sorte que la plate-forme restera à la fois rapide et fiable.