Technologie und Infrastruktur → Redis: In-Memory-Lösungen

Redis: In-Memory-Lösungen

1) Wo Redis angemessen ist

• Cache (read-through/aside, TTL, SWR) und Sitzungen.
• Zähler und Quoten: Ratenlimitierung, Betrugsbekämpfung, Kampagnenlimits.
• Leaderboards/Ratings (ZSet), Empfehlungen „top N“.
• Warteschlangen/Event-Busse (Streams/PubSub), Outbox/Inbox, Retrays.
• Idempotenz (Schlüssel mit TTL), De-Dup-Webhooks.
• Geo (Suche nach nächstgelegenen Punkten), Bitmap (Flags, DAU).
• Aliase/Token und kurzlebige Autorisierungscaches.

2) Datenstrukturen und wann sie anzuwenden sind

String: Werte/Zähler („INCRBY“), idempotente Schlüssel.
Hash: Aggregate von Profilen/Config, Speicherung von „leichten“ Objekten.
Liste: einfache Warteschlangen (aber keine Replay/Offset-Semantik).
Set: einzigartige Elemente, Deduplizierung.
ZSet: Sortierung nach Score (Leaderboards, TTL-Kalender - „verzögerte“ Ereignisse).
Stream: nachhaltige Warteschlangen mit Verbrauchergruppen, 'XREADGROUP '/replay - für Webhooks, CDC, Retrays.
Geo: 'GEOADD/GEORADIUS' sind die nächsten Punkte/Merchants.
Bitmap/Bitfield: Serie von Flags (Logins nach Tag, DAU/WAU).
HyperLogLog: Ungefähre Unique (UU) billig aus dem Speicher.
Bloom/Cuckoo (Module): schnelle Verfügbarkeitsprüfungen, reduzieren „MISS“ zur Quelle.

• RedisJSON (JSON-Dokumente), RediSearch (Indexierung/Suche), RedisBloom (probabilistische Strukturen), TimeSeries (Metriken/Aggregationen).

3) Schlüssel, TTL und Speicherrichtlinien

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

Versionieren ('vN'), nur sinnvolle Dimensionen einbeziehen (Region/Währung/Sprache/Tenant).
Isolieren Sie die Schlüsselräume per tenant.

• Verwenden Sie eine TTL-Matrix (sec/min/h), fügen Sie Jitter (± 10-20%) hinzu, um Stampede zu vermeiden.
• Für Hotkeys - refresh-ahead und single-flight (ein Leader aktualisiert).

• 'allkeys-lru/lfu' ist ein gemeinsamer Cache ohne TTL-Abhängigkeit.
• „volatile-lru/lfu“ - nur Schlüssel mit TTL.
• 'noeviction' - Schreibfehler bei Überlauf (sicherer für kritische Warteschlangen/Zähler).
• Passen Sie das Skript an und überwachen Sie immer 'evicted _ keys'.

4) Transaktionen, Pipelines und Skripte

Piplines: Reduzieren Sie RTT, gruppieren Sie 10-100 Teams.
Transaktionen (MULTI/EXEC): Isolieren Sie die Lesungen nicht, sondern führen Sie das Paket atomar aus.
Optimistic locking: „WATCH key“ → Überprüfung der → „MULTI/EXEC“.
Lua-Skripte: serverseitige atomare Logik (rate limit, locks, composite-Operationen).

5) Warteschlangen und Busse: Liste gegen Stream

List + 'BRPOP' - einfach, aber keine Verbrauchergruppen, Offset/Replay, schwache Sturzresistenz.
Stream: 'XADD → XREADGROUP → XACK', Retry-Deadletter (unspektakulär in N Minuten), Partitionierung nach Schlüssel. Empfohlen für PSP/KYC Webhooks, ausstehende Auszahlungen/Benachrichtigungen.

Prioritätswarteschlangen: Mehrere Streams nach Prioritäten, Verbraucher „saugen“ zuerst aus dem Hoch.
Verzögerte Aufgaben: ZSet, wobei score = timestamp; periodisch „ZRANGEBYSCORE“ ≤ jetzt → Übertragung in Stream.

6) Hohe Verfügbarkeit und Skalierung

Replikation: master→replica (Read-Scale)

Sentinel: automatischer Failover-Master, Erkennung, Client-URIs.
Redis Cluster: Scharnieren auf 16384 Slots, horizontal scale-out. Schlüssel, die mehrere Strukturen verwenden, in Hashtags'{order: 123} 'einwickeln.

• Für Cache/Sitzungen - Cluster/Replikate, 'Client-Side Hashing' wird vom SDK unterstützt.
• Für Warteschlangen/Streams - minimieren Sie Cross-Slot-Operationen; Partitionieren Sie nach Domain-Schlüsseln.

7) Persistenz: RDB, AOF und Backups

RDB (Snapshots): schneller, sparsamer; Verlustrisiko der letzten Sekunden/Minuten.
AOF (Journal): weniger Verluste; „everysec/always“ -Modi. AOF-Kompression und periodisches Umpacken.
Hybrid: RDB + AOF → schnelle Erholung + moderate Verluste.
Backups: Snapshots und Kopien von AOF im Objektspeicher; Überprüfen Sie die Wiederherstellung regelmäßig.

Für kritische Warteschlangen/Idempotenz wählen Sie AOF 'everysec' + Replikation.

8) Sicherheit und Compliance

AUTH/ACL: Rollen per App, Verbot „gefährlicher“ Befehle ('FLUSHALL', 'KEYS').
TLS pro Client-Server und Zwischen-Knoten-Links; feste egress-IP.
Netzsegmentierung: private Subnetze, SG/NACL; Zugriff nur von den gewünschten Diensten/Neympaces.
Geheimnisse nicht protokollieren; PAN/PII bei Redis - nur Token/Derivate.
Schlüsselbefehle: Vermeiden Sie' KEYS'- verwenden Sie' SCAN'.

9) Beobachtbarkeit und SLO

• Latency (P95/P99), `instantaneous_ops_per_sec`, `connected_clients`.
• Hit ratio, evicted_keys, expired_keys.
• Memory: used, fragmentation ratio, RSS, allocator stats.
• Replikation lag, AOF/RDB Frequenzen und Größen, Gabelzeit.
• Streams: PEL (pending entries list), delivery latency, retry count.

• Redis P99-Operationen ≤ 5-10 ms.
• Evictions ≤ 1 %/Stunde (Cache-Raum).
• Stream delivery P99 ≤ 500 мс, retry rate < 2%.

10) FinOps und Ressourcenplanung

Speicher teuer: Messen Sie $/GB-mes RAM vs sparen Sie Anfragen nach Herkunft/DB.
Aktivieren Sie die Kompression von Werten> 1-2 KB (siehe CPU).
Die LFU kann mit weniger Volumen einen besseren Treffer liefern.
Für Bilder/große Blobs - nicht Redis: Verwenden Sie CDN + Objektspeicher.

11) Muster für iGaming/Fintech

11. 1 Rate limiting (Schiebefenster, Lua)

Idee: „INCRBY“ im Fensterschlüssel + TTL; Lua prüft atomar das Limit und erhöht.

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 Idempotenz von Anfragen

Schlüssel 'idemp: {request _ id}' mit TTL 24h, Wert ist Ergebnis/Status. Vor der Operation - überprüfen Sie die Verfügbarkeit.

11. 3 Leaderboards

`ZINCRBY leaderboard:game:{g} score user:{u}` → `ZREVRANGE... WITHSCORES`.
Für die Top N nach Region/Tenant - einzelne ZSet oder Präfixe.

11. 4 PSP Webhooks Warteschlange

„XADD psp: webhooks...“ → der Verbrauchergruppe „XGROUP CREATE psp: webhooks g1 $“.
Retrays von „hängenden“ Nachrichten über PEL-Scans („XPENDING“ → „XCLAIM“).

11. 5 Ausstehende Zahlungen

ZSet 'payout: due' (score = epoch) → worker überträgt die fertigen Elemente periodisch in den Stream 'payout: exec' mit Deduplizierung.

11. 6 Betrugsbekämpfungszähler

Kombination „PFADD“ (einzigartig) + „INCR“ (Intensität) + Geo/ASN-Tags; Trigger zur manuellen Überprüfung.

12) Arbeit mit Speicher und Leistung

Pools von Kundenverbindungen; Reduzieren Sie die RTT (Keep-Alive).
Bevorzuge Pipelines zu einem Bündel von Befehlen.
Achten Sie auf große Tasten ('MEMORY USAGE', 'SCAN') - es ist besser, Objekte zu zerkleinern.
Hash mit einer kleinen Anzahl von Feldern ist wirtschaftlicher als viele einzelne Schlüssel.
Aktivieren Sie io-threads (read-heavy), wenn der Gewinn durch Tests bestätigt wird.
Vermeiden Sie häufige' FLUSHDB/ALL 'in der Produktion; Steuerung über Präfixe und 'UNLINK' zur sicheren Entfernung.

13) Multi-Tenant und Isolation

Einzelne Cluster/Instanzen oder logische DB per-tenant (wenn die Last klein ist).
Schlüssel-/Speicherkontingente, getrennte ACLs.
Präfixe in Schlüsseln und Metriken nach Namespace.

14) Locking und Konsistenz

SET Schlüssel val NX PX = ttl - simple mutex.
Redlock: vorsichtig verwenden; für verteilte kritische Transaktionen ist es besser, sich auf die „Quelle der Wahrheit“ (DB/ledger) und idempotente Operationen zu verlassen.
Atomare Operationen und Lua statt „langer“ Sperren bevorzugen.

15) Anti-Muster

Speicherung großer Blobs/Bilder - Überlastung von RAM und Netzwerken.
Finanzielle Invarianten (Saldo) nur bei Redis.
„KEYS“ und „Scan der Welt“ in der Produktion.
Kein TTL/Jitter - Dogpile nach Ablauf.
Die Richtlinie „allkeys-“ auf den kritischen Warteschlangen → den Verlust der Daten bei den Drücken.
Mischen Sie Warteschlangen, Cache und Sitzungen in einer Instanz ohne Quoten und Prioritäten.
Lua-Skripte, die an Schlüsseln verschiedener Slots in Cluster arbeiten.

16) Checkliste Umsetzung

1. Definieren Sie Rollen: Cache/Sitzungen, Warteschlangen/Streams, Zähler/Limits - Verteilen Sie sie auf Instanzen/Cluster.
2. Wählen Sie maxmemory-policy unter der Aufgabe; Grenzen setzen und evictions überwachen.
3. Schlüsselbenennung, Schaltungsversionen, TTL-Matrix + Jitter; Einzelflug für Top-Schlüssel.
4. Für Warteschlangen - Streams (Gruppen, Retrays, DLQ), für verzögerte - ZSet + Übertragung.
5. HA: Replikation + Sentinel oder Redis Cluster; Überprüfen Sie den Fehler des Clients.
6. Persistenz: RDB/AOF unter Szenario; regelmäßige Backups und Wiederherstellungstests.
7. Sicherheit: ACL, TLS, private Netzwerke, Verbot gefährlicher Befehle.
8. Beobachtbarkeit: latency, ops/sec, memory, evictions, replication lag, stream PEL.
9. FinOps: Speicherprofile, große Schlüssel, Kompression, LFU; Vermeiden Sie Redis für große Blobs.
10. Dokumentation von Mustern (Rate-Limit, Idempotenz, Leaderboards) und Belastungstests.

Ergebnis

Redis ist das „multifunktionale Schweizer Messer“ der Geschwindigkeit: Cache, Warteschlangen, Zähler, Leaderboards, Geo- und probabilistische Strukturen. Seine Stärke liegt in der richtigen Auswahl der Datenstrukturen, der Disziplin TTL/Behinderung, der Atomarität der Operationen sowie der durchdachten NA/Persistenz und Beobachtbarkeit. Verwenden Sie Redis, wo Millisekunden und ein hoher RPS wichtig sind, während Sie kritische Invarianten (Geld, Buchhaltung) der „Quelle der Wahrheit“ überlassen - damit die Plattform sowohl schnell als auch zuverlässig bleibt.