Wir verwenden Redis auf Trello für kurzlebige Daten, die wir verlieren würden. Wir speichern die Daten in Redis nicht auf der Festplatte und verwenden allkeys-lru, sodass wir dort nur Dinge speichern, die jederzeit mit nur sehr geringen Unannehmlichkeiten für die Benutzer entfernt werden können (z. B. vorübergehend ein falscher Benutzerstatus angezeigt wird). Davon abgesehen geben wir ihm mehr als das 5-fache des Speicherplatzes, den es benötigt, um seinen tatsächlichen Arbeitssatz zu speichern, und wählen aus 10 Schlüsseln für den Ablauf aus, sodass wir wirklich nie sehen, dass etwas rausgeschmissen wird, das wir verwenden.
-
Es ist unser Pubsub-Server. Wenn ein Benutzer etwas mit einem Board oder einer Karte macht, möchten wir eine Nachricht mit diesem Delta an alle Websocket-verbundenen Clients senden, die das geänderte Objekt abonniert haben, sodass alle unsere Node-Prozesse einen Pubsub-Kanal abonniert haben, der sich ausbreitet diese Nachrichten, und sie geben diese an die entsprechend berechtigten und abonnierten Websockets weiter.
-
Wir verwenden es SOWEIT, um socket.io zu unterstützen, aber da wir nur die Websockets verwenden und da socket.io zu gesprächig ist, um es so zu skalieren, wie wir es im Moment brauchen, haben wir einen Patch, der alle außer dem einen Kanal deaktiviert ist für uns notwendig.
-
Für unsere Benutzer, die keine Websockets haben, müssen wir eine Liste der Aktionen führen, die auf jedem Objektkanal seit der letzten Abfrage des Benutzers stattgefunden haben. Dazu verwenden wir eine Liste, die wir auf die letzten 100 Elemente begrenzen, und einen Hilfszähler, der angibt, wie viele Elemente der Liste seit ihrer Erstellung hinzugefügt wurden. Wenn wir also eine Umfrageanfrage von einem solchen Browser beantworten, können wir das letzte Element überprüfen, das er gemeldet hat, und nur Nachrichten senden, die seitdem zur Warteschlange hinzugefügt wurden. Dadurch wird eine Abfrage in den meisten Fällen auf eine Berechtigungsprüfung und eine einzelne Redis-Schlüsselprüfung reduziert, was sehr schnell geht.
-
Wir speichern einige flüchtige Daten über den aktiven Status verbundener Benutzer in Redis, da sich diese Daten häufig ändern und nicht auf der Festplatte gespeichert werden müssen.
-
Wir speichern kurzlebige Schlüssel, um OAuth-Anmeldungen in Redis zu unterstützen.
Wir lieben Redis; Sobald Sie eine Instanz davon eingerichtet und ausgeführt haben, möchten Sie sie für alle möglichen Dinge verwenden. Das einzige wirkliche Problem, das wir damit hatten, war, dass Clients, die langsam konsumierten, den verfügbaren Platz belegten.
Wir verwenden MongoDB für unsere traditionelleren Datenbankanforderungen.
