失っても大丈夫な一時的なデータには、TrelloでRedisを使用します。 Redisのデータをディスクに永続化せず、allkeys-lruを使用するため、ユーザーにごくわずかな不便をかけるだけで、いつでもキックアウトできるもののみを保存します（たとえば、ユーザーのステータスが一時的に間違っている場合など）。そうは言っても、実際のワーキングセットを保存するために必要なスペースの5倍以上を提供し、有効期限用に10個のキーから選択するため、使用しているものが追い出されることはありません。
-
それは私たちのpubsubサーバーです。ユーザーがボードまたはカードに対して何かを行うとき、変更されたオブジェクトにサブスクライブされているすべてのWebSocket接続クライアントにそのデルタを含むメッセージを送信する必要があるため、すべてのノードプロセスは伝播するpubsubチャネルにサブスクライブされますこれらのメッセージは、適切に許可およびサブスクライブされたWebSocketに伝播されます。
-
私たちはsocket.ioをバックアップするためにそれを使用しますが、websocketのみを使用し、socket.ioはおしゃべりすぎて現時点で必要なようにスケーリングできないため、1つのチャネルを除くすべてを無効にするパッチがあります。私たちに必要です。
-
WebSocketを持っていないユーザーの場合、ユーザーの最後のポーリング要求以降に各オブジェクトチャネルで発生したアクションのリストを保持する必要があります。そのために、最新の100個の要素を上限とするリストと、リストが作成されてからリストに追加された要素の数の補助カウンターを使用します。そのため、このようなブラウザからのポーリングリクエストに応答するときは、最後に表示されたと報告された要素を確認し、それ以降にキューに追加されたメッセージのみを送信できます。そのため、ほとんどの場合、ポーリングリクエストはパーミッションチェックと単一のRedisキーチェックになります。これは非常に高速です。
-
接続されたユーザーのアクティブステータスに関する一時的なデータをRedisに保存します。これは、データが頻繁に変更され、ディスクに保持する必要がないためです。
-
RedisでのOAuthログインをサポートするために、有効期間の短いキーを保存します。
Redisが大好きです。インスタンスを起動して実行したら、あらゆる種類の用途に使用できます。私たちが抱えていた唯一の本当の問題は、消費の遅いクライアントが利用可能なスペースを使い果たしてしまうことです。
従来のデータベースのニーズにはMongoDBを使用しています。