Wir stellen Ihnen Rump vor: eine tolle Möglichkeit Redis-Datenbanken mit Dumps zu synchronisieren

Wir freuen uns, unser erstes Open-Source-Projekt ankündigen zu können: Rump!

Rump ist ein winziges Tool, das sich auf eine einfache Sache konzentriert: Live-Daten aus einem AWS-ElastiCache-Redis-Cluster zu erhalten.

Wir standen vor diesem Problem, als wir versuchten, unsere Staging-Redis-Container mit unserem Produktions-Cluster zu synchronisieren. Bei Sticker Mule machen wir stark von Docker und CoreOS Gebrauch und verlassen uns auf einen ElastiCache-Cluster für unsere Redis-Bedürfnisse in der Produktion.

In letzter Zeit wollten wir unsere Staging-Umgebung so nah wie möglich an unsere Produktionsumgebung heranführen, und Redis ist ein Teil davon. Hier ist die Reise, die letztendlich zu Rump führte.

Nicht blockieren

Wir hatten eine einfache Anforderung: Die Produktion sollte nicht blockiert werden, während wir Daten abrufen. Die Single-Thread-Natur von Redis ist ein wichtiger Aspekt, den es zu berücksichtigen gilt.

Überraschenderweise entdeckten wir, dass ElastiCache mit einigen deaktivierten Befehlen ausgeliefert wird. Im Grunde genommen, alle Befehle, mit denen Sie Daten sicher übertragen können.

BGSAVE

Der übliche Weg, ein Backup einer Redis-Datenbank manuell auszulösen, ist, das Auslösen eines BGSAVE und das Warten auf dessen Beendigung im Hintergrund - eine nicht-blockierende Operation. Leider ist dies deaktiviert, es sei denn, Sie verwenden die AWS-interne Implementierung der Snapshot-Funktion.

SLAVEOF

Das Einrichten von Slaves ist eine weitere interessante Option die Redis bietet, und es wäre die perfekte Wahl für uns gewesen.

Der Plan war, die Staging-Redis-Container vorübergehend als Slaves unseres Produktionsclusters einzurichten, um Live-Daten zu erhalten. Leider ist auch SLAVEOF deaktiviert und es gibt keine Möglichkeit, Slaves zu einer ElastiCache-Instanz hinzuzufügen.

Existierende Tools

Es gibt viele tolle Redis-Tools die versuchen, die Verwaltung von Redis-Servern, das Dumpen nach JSON usw. zu vereinfachen.

Das Problem ist, dass die meisten der stabilen, unterstützten Tools den Befehl KEYS verwenden, um Schlüssel zu erhalten, und dann auf den Schlüsseln operieren. Der KEYS-Befehl hat eine O(N)-Komplexität, die Redis stark blockiert, wenn N hoch ist, bis alle Schlüssel zurückgegeben werden. Staging-Container werden häufig erstellt und vernichtet und wir haben eine gute Anzahl von Schlüsseln. Wir wollen unseren eigenen Server nicht DoS machen.

Es war klar, dass wir ein einfaches Tool brauchten, um nur die Synchronisierung durchzuführen. Wir fingen an mit SCAN zu experimentieren, um die Schlüssel zu erhalten, und mit DUMP/RESTORE, um die Werte zu erhalten/zu setzen.

SCAN`` ist ein O(1)-Befehl, der sicher auf einem Produktionsserver ausgeführt werden kann, um alle Schlüssel zu erhalten, und deshalb muss seine Implementierung anders alsKEYSsein.SCAN``` liefert eine Gruppe von Schlüsseln, die aktuell in der Datenbasis vorhanden sind, und einen Positionsanzeiger zur nächsten Gruppe.

DUMP/RESTORE machen die Aufgabe des Lesens/Schreibens von Werten unabhängig vom Schlüsseltyp.

Mit diesem Gedanken im Hinterkopf, hier ist es, was Rump alles bietet:

• Nicht-blockierendes, progressives Lesen von Schlüsseln über SCAN.
• TYPE-unabhängige Werteoperationen über DUMP/RESTORE.
• Geleitete SCAN- und DUMP/RESTORE-Operationen.
• Das Lesen vom Quellserver und das Schreiben auf den Zielserver erfolgen gleichzeitig. Rump speichert nicht alle Schlüssel vor dem Schreiben auf den Zielserver.
• Einzelne plattformübergreifende Binärdatei, keine Abhängigkeiten.
• Minimaler Fußabdruck, UNIX-Philosophie, es macht nur eine Sache mit zwei Flags.

Wir hoffen, dass das Tool sich für diejenigen als nützlich erweisen wird, die die gleichen Probleme wie wir hatten, und vielen, vielen Dank an Redis für die Unterstützung einer so breiten Palette von Befehlen!

Anmerkung: Wenn dies für Sie von Interesse ist, und Sie nach einem Unternehmen suchen, in dem talentierte Leute gerne arbeiten - bewerben Sie sich doch bei uns.