Ние използваме Redis в Trello за ефимерни данни, които бихме могли да загубим. Ние не съхраняваме данните в Redis на диск и ги използваме allkeys-lru, така че съхраняваме там само неща, които могат да бъдат изхвърлени по всяко време само с много незначително неудобство за потребителите (например моментално виждане на неправилно потребителско състояние). Като се има предвид това, ние му даваме повече от 5 пъти пространството, от което се нуждае, за да съхранява действителния си работен комплект и избираме измежду 10 ключа за изтичане на валидност, така че наистина никога не виждаме нищо да бъде изхвърлено, което използваме.
-
Това е нашият pubsub сървър. Когато потребител направи нещо на дъска или карта, ние искаме да изпратим съобщение с тази делта до всички клиенти, свързани с уеб сокет, които са абонирани за обекта, който се промени, така че всички наши процеси на Node са абонирани за pubsub канал, който се разпространява тези съобщения и те ги разпространяват до подходящо разрешени и абонирани уебсокети.
-
Ние НЕЩО го използваме, за да подкрепим socket.io, но тъй като използваме само websockets и тъй като socket.io е твърде бъбрив, за да се мащабира, както ни е необходимо в момента, имаме корекция, която деактивира всички освен единия канал, който е необходимо за нас.
-
За нашите потребители, които нямат уебсокети, трябва да поддържаме списък с действията, които са се случили във всеки обектен канал след последната заявка за анкета на потребителя. За това използваме списък, който ограничаваме до най-новите 100 елемента и допълнителен брояч на колко елемента са добавени към списъка, откакто е създаден. Така че, когато отговаряме на заявка за анкета от такъв браузър, можем да проверим последния елемент, който съобщава, че е видял, и да изпратим само всички съобщения, които са добавени към опашката оттогава. Така че това свежда заявката за анкета само до проверка на разрешенията и проверка на единичен ключ Redis в повечето случаи, което е много бързо.
-
Съхраняваме някои ефимерни данни за активното състояние на свързани потребители в Redis, тъй като тези данни се променят често и не е необходимо да се съхраняват на диск.
-
Ние съхраняваме краткотрайни ключове, за да поддържаме OAuth влизания в Redis.
Ние обичаме Redis; след като имате екземпляр от него и работи, искате да го използвате за всякакви неща. Единственият реален проблем, който сме имали с него, е с бавно консумиращите клиенти, които изяждат наличното пространство.
Използваме MongoDB за нашите по-традиционни нужди от база данни.
