Usamos Redis en Trello para datos efímeros que estaríamos de acuerdo con perder. No conservamos los datos en Redis en el disco, y los usamos allkeys-lru, por lo que solo almacenamos cosas que se pueden eliminar en cualquier momento con solo inconvenientes menores para los usuarios (por ejemplo, ver momentáneamente un estado de usuario incorrecto). Dicho esto, le damos más de 5 veces el espacio que necesita para almacenar su conjunto de trabajo real y elegir entre 10 claves para el vencimiento, por lo que realmente nunca vemos que se elimine nada de lo que estamos usando.
-
Es nuestro servidor pubsub. Cuando un usuario hace algo en un tablero o una tarjeta, queremos enviar un mensaje con ese delta a todos los clientes conectados a websocket que están suscritos al objeto que cambió, por lo que todos nuestros procesos de Nodo están suscritos a un canal pubsub que se propaga esos mensajes, y los propagan a los websockets debidamente autorizados y suscritos.
-
En cierto modo lo usamos para respaldar socket.io, pero dado que solo usamos los websockets, y dado que socket.io es demasiado hablador para escalar como lo necesitamos en este momento, tenemos un parche que deshabilita todos menos el canal que es necesario para nosotros.
-
Para nuestros usuarios que no tienen websockets, debemos mantener una lista de las acciones que han ocurrido en cada canal de objeto desde la última solicitud de encuesta del usuario. Para eso usamos una lista que limitamos a los 100 elementos más recientes y un contador auxiliar de cuántos elementos se han agregado a la lista desde que se creó. Entonces, cuando respondemos una solicitud de encuesta desde un navegador de este tipo, podemos verificar el último elemento que informa que ha visto y solo enviar los mensajes que se han agregado a la cola desde entonces. Entonces, en la mayoría de los casos, una solicitud de encuesta se reduce a solo una verificación de permisos y una sola verificación de clave de Redis, lo cual es muy rápido.
-
Almacenamos algunos datos efímeros sobre el estado activo de los usuarios conectados en Redis, porque esos datos cambian con frecuencia y no es necesario conservarlos en el disco.
-
Almacenamos claves de corta duración para admitir inicios de sesión OAuth en Redis.
Nos encanta Redis; una vez que tenga una instancia en funcionamiento, querrá usarla para todo tipo de cosas. El único problema real que hemos tenido es que los clientes que consumen lentamente consumen el espacio disponible.
Usamos MongoDB para nuestras necesidades de bases de datos más tradicionales.
