Redis AOF - Fälle, in denen es zur Verbesserung der Leistung audacious abgeschaltet werden kann

Redis ist ein leistungsstarker In-Memory-Datenspeicher. Schnelligkeit ist von entscheidender Bedeutung, jedoch besteht aufgrund der "In-Memory"-Natur das Risiko, dass alle Daten verloren gehen, wenn der Server neu gestartet wird. Um dies zu verhindern, bietet Redis zwei Persistenzoptionen an.

1. RDB (Snapshotting): Speichert einen Snapshot aller Daten zu einem bestimmten Zeitpunkt auf der Festplatte.

2. AOF (Append Only File): Protokolliert alle Schreibbefehle sequenziell in einer Protokolldatei.

AOF gewährleistet eine nahezu verlustfreie Datenspeicherung im Vergleich zu RDB (in der Regel innerhalb von 1 Sekunde). Allerdings führt das Protokollieren aller Schreibvorgänge in eine Datei zu offensichtlichen Leistungskosten.

„Ist AOF wirklich in allen Redis-Anwendungsfällen notwendig?“

Zusammenfassend lässt sich sagen: „Nein, überhaupt nicht.“

Heute wollen wir die Fälle klar unterscheiden, in denen die AOF-Einstellung nicht verwendet werden muss, und im Gegenteil, die, in denen AOF zwingend erforderlich ist.

Fälle, in denen AOF nicht unbedingt benötigt wird

Der Kernwert von AOF liegt in der Datenhaltbarkeit (Durability). Wenn diese Haltbarkeit für die Daten nicht wichtig ist, kann AOF zu einer unnötigen Leistungseinbuße werden.

1. Wenn es nur als Cache verwendet wird

Das ist das häufigste Beispiel.

• Grund: Die Daten im Cache sind nicht das „Original“. Eine separate „Quelle der Wahrheit“, wie eine Datenbank oder eine andere API, existiert.

• Bei Datenverlust: Selbst wenn Redis neu gestartet wird und der Cache vollständig geleert wird, wird die Anwendung nur kurz langsamer (Cache Miss), und die Originaldaten können erneut gelesen werden, um den Cache aufzufüllen (Cache-Warm up). Die Daten gehen nicht dauerhaft verloren.

• Fazit: Wenn es als Cache verwendet wird, wird oft sowohl AOF als auch RDB deaktiviert. Das vollständige Entfernen von Festplatten-I/O maximiert die rein in-memory Geschwindigkeit von Redis.

2. Celery-Broker / Ergebnis-Backend (weniger kritische Aufgaben)

Redis wird häufig zusammen mit Celery verwendet. Bei der AOF-Konfiguration von Redis als Broker und Ergebnis-Backend hängt es von der „Wichtigkeit der Aufgaben“ ab.

• Grund: Wenn die Aufgaben, die mit Celery verarbeitet werden, „egal sind, ob sie fehlschlagen“ oder „einfach wiederholt werden können“, dann ist AOF nicht erforderlich.

• Beispiele:

  • Benutzerprotokollanalyse (einige Sekunden Protokolldaten gehen verloren, ist kein großes Problem)

  • Regelmäßige Datenbereinigung (kann in der nächsten Periode erneut durchgeführt werden)

  • Thumbnail-Bilderstellung (Originalbilder sind vorhanden, also kann es neu erstellt werden)

• Fazit: In solchen Szenarien kann es vorkommen, dass die im Queue wartenden Aufgaben oder Ergebnisse verloren gehen, wenn der Redis-Server abstürzt. Wenn dieser Verlust jedoch geschäftlich „verkraftbar“ ist, ist es klüger, AOF zu deaktivieren und die Leistung des Brokers zu sichern.

3. Einfache Statistiken und Echtzeitdaten (flüchtig)

Wenn es darum geht, kurzfristige Trends zu beobachten oder schnell aktualisierte Daten zu verarbeiten.

• Grund: Daten werden entweder in sehr kurzen Intervallen aktualisiert oder ein Snapshot zu einem bestimmten Zeitpunkt hat nur wenig Bedeutung.

• Beispiele:

  • Zahl der Website-Besucher in den letzten 1 Minute

  • Echtzeit-Spiel-Rangliste (ändert sich sekündlich)

  • Temporäre Sitzungsdaten (verfallen innerhalb von Minuten)

• Fazit: Es sind ohnehin nur Daten, die schnell verschwinden oder aktualisiert werden. Es ist viel wichtiger, viele Schreibanfragen schnell zu verarbeiten, als ein paar Sekunden an Daten zu verlieren. AOF ist für solche Umgebungen nicht geeignet.

Fälle, in denen die Verwendung von AOF dringend empfohlen wird

Im Gegenteil, wenn der Verlust von Redis-Daten ernsthafte Probleme verursachen kann, ist AOF eine Notwendigkeit und keine Wahl.

1. „Zuverlässige“ Nachrichtenwarteschlange (Kritische Celery-Jobs)

Das ist das genaue Gegenteil des obigen Celery-Beispiels.

• Grund: Die Aufgabe selbst steht in Verbindung mit Geld oder kritischen Geschäftslogiken.

• Beispiele:

  • Bezahlungsbearbeitungsanfragen

  • Bestätigung der Registrierung und Versand der Bestätigungs-E-Mail

  • Auftragsbearbeitung

• Fazit: Wenn der Benutzer auf die Schaltfläche 'Zahlung' klickt und Redis neu gestartet wird, wodurch die Anfrage verloren geht, ist das ein ernsthaftes Problem. In solchen Szenarien muss AOF mit der Option fsync everysec (Standard) aktiviert werden, um sicherzustellen, dass die Aufgabe sofort in der Warteschlange auf die Festplatte geschrieben wird.

2. Wenn Redis als Hauptdatenbank verwendet wird

Wenn Redis nicht nur als einfacher Cache, sondern als Quelle der Wahrheit (Source of Truth) verwendet wird.

• Grund: Da keine separate Datenbank existiert und Redis selbst die Originaldaten speichert, bedeutet ein Datenverlust den sofortigen Verlust dieser Daten.

• Beispiele:

  • Benutzerprofilinformationen

  • Benutzersitzungen, die dauerhaft gespeichert werden müssen

  • Informationen über Spielwährung (Gold, Gegenstände)

• Fazit: In diesem Fall ist AOF erforderlich, und es sollte in Kombination mit RDB-Snapshots verwendet werden, um Backup- und Wiederherstellungsstrategien zu entwickeln.

3. Transaktions- und aggregierte Daten

Wenn die Konsistenz und Genauigkeit der Daten von größter Bedeutung sind.

• Grund: RDB speichert nur einen bestimmten Zeitpunkt, sodass alle Daten nach dem letzten Snapshot verloren gehen. AOF speichert alle Änderungsverläufe, wodurch Datenverluste minimiert (maximal 1 Sekunde) werden können.

• Beispiele:

  • Follow/Unfollow-Beziehungen

  • Genauigkeiten bei der Zählung von Stimmen

  • Finanzdaten (einfache Ein- und Auszahlungsverläufe)

• Fazit: Wenn die ultimative Konsistenz der Daten entscheidend ist, ist die „Append-Only“-Eigenschaft von AOF weitaus geeigneter als RDB.

Fazit: Abwägung zwischen Haltbarkeit und Leistung

AOF ist eine leistungsstarke Funktion von Redis, die Haltbarkeit (Durability) bietet. Allerdings hat diese Funktion auch ihren Preis in Bezug auf die Leistung (Performance).

Wenn Sie unsicher sind, ob Sie AOF aktivieren sollten oder nicht, sollten die Entwickler die folgenden Fragen beantworten:

„Wird unser Service ein ernsthaftes Problem haben, wenn der Redis-Server ohne Vorwarnung ausfällt und kürzlich (RDB) oder seit 1 Sekunde (AOF) Daten verloren gehen?“

• „Nein, wir können es einfach neu berechnen (Cache).“ -> Bitte AOF deaktivieren.

• „Ja, die Zahlungsdetails würden verschwinden.“ -> Bitte AOF aktivieren.

An jeder technischen Entscheidung ist, wie immer, keine Antwort richtig oder falsch. Es ist entscheidend, die spezifischen Datenmerkmale und Anforderungen Ihres Services genau zu verstehen und eine geeignete Abwägung zu treffen.