Używamy Redis na Trello do efemerycznych danych, których utratę bylibyśmy w porządku. Nie przechowujemy danych w Redis na dysku i używamy ich allkeys-lru, więc przechowujemy tylko te rzeczy, które mogą zostać wyrzucone w dowolnym momencie z bardzo niewielkimi niedogodnościami dla użytkowników (np. chwilowe widzenie nieprawidłowego statusu użytkownika). Biorąc to pod uwagę, dajemy mu ponad pięciokrotnie więcej miejsca, którego potrzebuje do przechowywania rzeczywistego zestawu roboczego, i wybieramy spośród 10 kluczy do wygaśnięcia, więc naprawdę nigdy nie widzimy wyrzucanych niczego, z czego korzystamy.
-
To nasz serwer pubsub. Kiedy użytkownik robi coś z tablicą lub kartą, chcemy wysłać wiadomość z tą deltą do wszystkich klientów podłączonych do gniazda sieciowego, którzy subskrybują obiekt, który się zmienił, więc wszystkie nasze procesy Node są subskrybowane do kanału pubsub, który się propaguje te wiadomości i rozsyłają je do odpowiednio upoważnionych i subskrybowanych gniazd sieciowych.
-
DUŻO używamy go do tworzenia kopii zapasowej socket.io, ale ponieważ używamy tylko gniazd sieciowych i ponieważ socket.io jest zbyt gadatliwy, aby skalować, jak potrzebujemy w tej chwili, mamy łatkę, która wyłącza wszystkie kanały, z wyjątkiem jednego jest nam niezbędne.
-
Dla naszych użytkowników, którzy nie mają gniazd sieciowych, musimy przechowywać listę działań, które miały miejsce na każdym kanale obiektu od ostatniego żądania ankiety przez użytkownika. W tym celu używamy listy, którą ograniczamy do ostatnich 100 elementów, oraz pomocniczego licznika, ile elementów zostało dodanych do listy od czasu jej utworzenia. Kiedy więc odpowiadamy na żądanie ankiety z takiej przeglądarki, możemy sprawdzić ostatni zgłoszony element, który widział, i wysłać tylko te wiadomości, które zostały dodane do kolejki od tego czasu. W ten sposób żądanie ankiety sprowadza się do sprawdzenia uprawnień i pojedynczego sprawdzenia klucza Redis w większości przypadków, co jest bardzo szybkie.
-
Przechowujemy niektóre efemeryczne dane o aktywnym stanie podłączonych użytkowników w Redis, ponieważ te dane często się zmieniają i nie ma potrzeby utrwalania ich na dysku.
-
Przechowujemy klucze o krótkim czasie życia, aby obsługiwać logowanie OAuth w Redis.
Kochamy Redis; gdy już masz instancję i działa, chcesz jej używać do różnych rzeczy. Jedyny prawdziwy problem, jaki mieliśmy z tym, to fakt, że wolno konsumujący klienci pochłaniają dostępną przestrzeń.
Używamy MongoDB do naszych bardziej tradycyjnych potrzeb w zakresie baz danych.
