クライアントサービスアーキテクチャ：クライアントをメモリ内のデータ構造と同期させておく

Question

redis（高速メモリ内データストレージ）のセットをリアルタイムで更新するサービスがあります。 また、このredisインスタンスに接続されているアプリがあります。設定された内容をすべてのクライアントに表示することです。クライアントの設定によっては、セットの一部の要素が送信されないことに注意してください。

私はすべてのアップデートでセット内容全体を送信したくありません。 diffだけを送ることが可能でなければならず、私はどのアプローチを使うかを選択しています。 レールの

実装 - >クライアント接続：

• はを反応 - リアルタイムの状態を維持するための良いフィットのような音を反応させます。リアルタイムで小道具を更新すると、htmlは無料で最新の状態に保たれます。
• actioncable - レールアプリにウェブソケットを統合する最新のコンポーネントがあります。

サービス - > Redisのセット - >レール：

• 私は機能パブ/サブRedisのを使用してのRedisへの書き込みサービスが変更/更新された要素を送る設定作ることができます/削除し、セット自体を使って新しいクライアントにデータを送信するだけで、既存のものはpub/subを介して同期された状態に保たれます。
  1. サービスがセット
  2. サービスの要素を更新しようとしているRedisの
  3. にセットに要素を追加したサービスは、に要素を送信しますので、クライアントを更新するには、以下が行われますパブ/サブキューに登録されているパブ/サブキュー
  4. レールのアプリは、要素
  5. レールアプリを受け取り、更新を取得する必要があり、どれを参照するクライアントのリストをフィルタリング（通常、それはそれらのほとんどです）
  6. rails appが新しいアイテムをブロードキャストし、cliエントは、それが

その上で、私も例を削除/変更を実装する必要がありますレンダリング。 このアプローチはあまりにも複雑で低レベルなようです。物事は簡単にはずれてしまい、メモリに何度も複製されてしまいます。

• 代わりのパブ/サブ私はすべての変更が発生した場合は、レールのアプリの読み込みRedisのは、繰り返しの内容を設定して計算することができます。 redisがセットをメモリに保存するので、安価でなければなりません。 rails appが変更を検出すると、それはクライアントにブロードキャストされます。それでも、タイムアウトに基づいてメモリ内の何かが変更されたかどうかを確認する必要があるのは間違っています。

追加情報：多すぎるクライアントはありません。おそらく千人でしょう。このセットは1秒に1回、時にはそれ以上、時にはそれほど更新されません。

クライアントを状態と同期させておくための最良の方法は何ですか？反応の使用は正当化されていますか？そのような "diff"パターンのネイティブ反応実装がありますか？

Answer 1

ReactとActionCablesの両方を使用しているアプリがあります。

2人はかなりよく一緒に働いています。 ActionCables（これは他の同様のツールよりもユーザー制限のベンチマークが低い）の限界を理解することは重要ですが、何千人ものユーザーが同時に使用することを期待していない場合はうまく動作します。

Reactを使用するかどうかにかかわらず、Fluxパターンはソケット接続の状態を管理するために大きく進んでいると思います。 Vanilla FluxとReduxはどちらも優れた仲間であり、サーバーからの変更を聞き取り、その情報をアプリケーションの関連領域に広める素晴らしい仕事をしています。両方ともReactでの使用のために意図されていますが、実際にはフロントエンドフレームワークで使用できます。