Vi använder Redis på Trello för tillfälliga data som vi skulle vara okej om att förlora. Vi lagrar inte data i Redis till disk, och vi använder det allkeys-lru, så vi lagrar bara saker där som kan kastas ut när som helst med endast mycket mindre besvär för användarna (t.ex. att tillfälligt se en felaktig användarstatus). Med detta sagt ger vi den mer än 5 gånger så mycket utrymme som den behöver för att lagra sin faktiska arbetsuppsättning och väljer mellan 10 nycklar för utgångsdatum, så vi ser verkligen aldrig att någonting blir utslängt som vi använder.
-
Det är vår pubsubserver. När en användare gör något med ett kort eller ett kort vill vi skicka ett meddelande med det deltat till alla websocket-anslutna klienter som prenumererar på objektet som ändrades, så alla våra Node-processer prenumereras på en pubsub-kanal som sprider sig dessa meddelanden, och de sprider det till lämpligt behöriga och prenumererade websockets.
-
Vi använder den SOM HELST för att backa socket.io, men eftersom vi bara använder websockets, och eftersom socket.io är för chattig för att skala som vi behöver det för tillfället, har vi en patch som inaktiverar alla utom den ena kanalen som är nödvändigt för oss.
-
För våra användare som inte har websockets måste vi föra en lista över de åtgärder som har hänt på varje objektkanal sedan användarens senaste omröstningsförfrågan. För det använder vi en lista som vi begränsar till de senaste 100 elementen, och en hjälpräknare för hur många element som har lagts till i listan sedan den skapades. Så när vi svarar på en omröstningsförfrågan från en sådan webbläsare kan vi kontrollera det sista elementet som den rapporterar att den har sett, och bara skicka ner alla meddelanden som har lagts till i kön sedan dess. Så det får en omröstningsförfrågan ner till bara en behörighetskontroll och en enda Redis-nyckelkontroll i de flesta fall, vilket är väldigt snabbt.
-
Vi lagrar en del kortvarig data om den aktiva statusen för anslutna användare i Redis, eftersom dessa data ändras ofta och det inte är nödvändigt att lagra dem på disken.
-
Vi lagrar kortlivade nycklar för att stödja OAuth-inloggningar i Redis.
Vi älskar Redis; när du väl har en instans av den igång vill du använda den för alla möjliga saker. Det enda verkliga problemet vi har haft med det är att kunder som konsumerar långsamt äter upp det tillgängliga utrymmet.
Vi använder MongoDB för våra mer traditionella databasbehov.