We gebruiken Redis op Trello voor kortstondige gegevens die we niet zouden verliezen. We bewaren de gegevens in Redis niet op schijf, en we gebruiken het allkeys-lru, dus we slaan alleen dingen op die op elk moment kunnen worden verwijderd met slechts zeer klein ongemak voor gebruikers (bijvoorbeeld tijdelijk een onjuiste gebruikersstatus zien). Dat gezegd hebbende, we geven het meer dan 5x de ruimte die het nodig heeft om zijn daadwerkelijke werkset op te slaan en kiezen uit 10 sleutels voor het verstrijken, dus we zien echt nooit dat er iets wordt weggegooid dat we gebruiken.
-
Het is onze pubsub-server. Wanneer een gebruiker iets doet met een bord of een kaart, willen we een bericht met die delta sturen naar alle met websocket verbonden clients die zijn geabonneerd op het object dat is gewijzigd, dus al onze Node-processen zijn geabonneerd op een pubsub-kanaal dat zich verspreidt die berichten, en ze verspreiden dat naar de juiste geautoriseerde en geabonneerde websockets.
-
We gebruiken het SOORT om socket.io te back-uppen, maar omdat we alleen de websockets gebruiken, en omdat socket.io te spraakzaam is om te schalen zoals we het op dit moment nodig hebben, hebben we een patch die alles uitschakelt, behalve het ene kanaal dat is noodzakelijk voor ons.
-
Voor onze gebruikers die geen websockets hebben, moeten we een lijst bijhouden van de acties die op elk objectkanaal hebben plaatsgevonden sinds het laatste peilingverzoek van de gebruiker. Daarvoor gebruiken we een lijst die we beperken tot de meest recente 100 elementen, en een hulpteller van hoeveel elementen er aan de lijst zijn toegevoegd sinds deze is gemaakt. Dus als we een poll-verzoek van zo'n browser beantwoorden, kunnen we het laatste element controleren dat het rapporteert dat het heeft gezien, en alleen berichten verzenden die sindsdien aan de wachtrij zijn toegevoegd. Dus dat zorgt ervoor dat een peilingverzoek wordt teruggebracht tot slechts een machtigingscontrole en een enkele Redis-sleutelcontrole in de meeste gevallen, wat erg snel is.
-
We slaan enkele kortstondige gegevens over de actieve status van verbonden gebruikers op in Redis, omdat die gegevens vaak veranderen en het niet nodig is om ze op schijf te bewaren.
-
We slaan sleutels met een korte levensduur op om OAuth-aanmeldingen in Redis te ondersteunen.
We houden van Redis; als je er eenmaal een exemplaar van hebt, wil je het voor allerlei dingen gebruiken. Het enige echte probleem dat we ermee hebben gehad, is dat klanten die traag consumeren de beschikbare ruimte opeten.
We gebruiken MongoDB voor onze meer traditionele databasebehoeften.