Vi bruger Redis på Trello til flygtige data, som vi ville være okay med at miste. Vi bevarer ikke dataene i Redis til disk, og vi bruger dem allkeys-lru, så vi gemmer kun ting der, der kan smides ud til enhver tid med kun meget mindre gener for brugerne (f.eks. kortvarigt at se en forkert brugerstatus). Når det så er sagt, giver vi den mere end 5 gange den plads, den har brug for til at opbevare sit faktiske arbejdssæt og vælger mellem 10 nøgler til udløb, så vi ser aldrig noget blive smidt ud, som vi bruger.
-
Det er vores pubsub-server. Når en bruger gør noget ved et board eller et kort, vil vi sende en besked med dette delta til alle websocket-tilsluttede klienter, der abonnerer på det objekt, der ændrede sig, så alle vores Node-processer abonneres på en pubsub-kanal, der udbreder sig disse beskeder, og de udbreder det til de korrekt godkendte og abonnerede websockets.
-
Vi bruger det SOM GODT til at backe socket.io, men da vi kun bruger websockets, og da socket.io er for chatty til at skalere, som vi har brug for det i øjeblikket, har vi en patch, der deaktiverer alle undtagen den ene kanal, der er nødvendigt for os.
-
For vores brugere, der ikke har websockets, skal vi føre en liste over de handlinger, der er sket på hver objektkanal siden brugerens sidste poll-anmodning. Til det bruger vi en liste, som vi begrænser til de seneste 100 elementer, og en hjælpetæller for, hvor mange elementer der er blevet tilføjet til listen, siden den blev oprettet. Så når vi besvarer en afstemningsanmodning fra en sådan browser, kan vi tjekke det sidste element, den rapporterer, at den har set, og kun sende beskeder ned, som er blevet tilføjet til køen siden da. Så det får en afstemningsanmodning ned til kun en kontrol af tilladelser og en enkelt kontrol af Redis-nøgle i de fleste tilfælde, hvilket er meget hurtigt.
-
Vi gemmer nogle flygtige data om den aktive status for tilsluttede brugere i Redis, fordi disse data ændres ofte, og det er ikke nødvendigt at bevare dem på disken.
-
Vi gemmer kortlivede nøgler for at understøtte OAuth-login i Redis.
Vi elsker Redis; når du først har en instans af det oppe at køre, vil du gerne bruge det til alle mulige ting. Det eneste virkelige problem, vi har haft med det, er med langsomt-forbrugende kunder, der spiser den tilgængelige plads.
Vi bruger MongoDB til vores mere traditionelle databasebehov.