Ответ 1
Мы используем Redis на Trello для эфемерных данных, которые были бы в порядке с потерей. Мы не сохраняем данные в Redis на диске, и мы используем его allkeys-lru, поэтому мы сохраняем только то, что можно вытащить на любом с очень незначительными неудобствами для пользователей (например, мгновенное отображение неправильного статуса пользователя). При этом мы даем ему более 5-кратного пространства, необходимого для хранения его фактического рабочего набора, и выбираем из 10 ключей для истечения срока действия, поэтому мы действительно никогда не видим, чтобы что-то выходило из того, что мы используем.
-
Это наш сервер pubsub. Когда пользователь что-то делает с доской или картой, мы хотим отправить сообщение с этой дельта всем связанным с websocket клиентам, которые подписаны на измененный объект, поэтому все наши процессы Node подписаны на канал pubsub которые распространяют эти сообщения, и распространяют их на соответствующие разрешенные и подписанные websockets.
-
Мы используем его для back socket.io, но поскольку мы используем только websockets, и поскольку socket.io слишком chatty для масштабирования, как это необходимо в настоящий момент, у нас есть патч, который отключает все, кроме одного канала, который нам нужен.
-
Для наших пользователей, у которых нет веб-сайтов, мы должны сохранить список действий, которые произошли на каждом канале объекта, начиная с запроса последнего опроса пользователя. Для этого мы используем список, который мы закрываем для последних 100 элементов, и вспомогательный счетчик количества элементов, добавленных в список с момента его создания. Поэтому, когда мы отвечаем на запрос опроса из такого браузера, мы можем проверить последний элемент, который он сообщает, что он видел, и отправлять только сообщения, которые были добавлены в очередь с тех пор. Таким образом, в большинстве случаев запрос опроса проходит только до проверки разрешений и одной проверки ключа Redis, что очень быстро.
-
Мы сохраняем некоторые эфемерные данные об активном статусе подключенных пользователей в Redis, поскольку эти данные часто меняются, и нет необходимости сохранять их на диске.
-
Мы храним краткосрочные ключи для поддержки логинов OAuth в Redis.
Мы любим Редиса; если у вас есть экземпляр этого приложения, вы хотите использовать его для всех видов вещей. Единственная реальная проблема, с которой мы столкнулись, - это медленные клиенты, которые съедают доступное пространство.
Мы используем MongoDB для наших более традиционных потребностей в базе данных.