JRedis の同期実装を使用していますが、redis サーバーとの通信を非同期に切り替える予定です。
しかしその前に、alphazero の jredis のJRedisFuture実装が本番環境で使用するのに十分安定しているかどうかをコミュニティに尋ねたいと思います。
使っている人や経験のある人はいますか？
ありがとう！
1 に答える
1
JRedis がトランザクション セマンティクス (Redis 1.3.n、JRedis マスター ブランチ) をサポートするようになると、十分に「安定」するはずです。
非トランザクション コマンド用の Redis プロトコルは、それ自体がアトミックであり、破壊的なコマンドが送信され、読み取りフェーズで接続が失敗したときに、回復不能な障害のウィンドウを許可します。クライアントは、Redis が実際に最後のリクエストを処理したかどうかを知る方法はありませんが、ネットワーク障害が原因で応答がドロップされました (たとえば)。基本的な要求/応答クライアントでさえ、これに影響されやすいです (これは Java に限ったことではないと思います)。
Redis のプロトコルは、DML および DDL タイプのコマンド (たとえば、コマンド シーケンス番号がない) でメタデータを (まったく) 必要としないため、この失敗のウィンドウが開かれます。
パイプライン処理を使用すると、書き込まれているコマンドと読み取られている応答との間に順次関連付けがなくなります。(パイプは、Redis が同時に読み取られる応答を発行する原因となったコマンドの後ろに N コマンドのコマンドを送信しています。何かがうまくいかない場合、空中にはたくさんの皿があります:)
とはいえ、パイプ内のすべての将来のオブジェクトには障害が発生したというフラグが立てられ、どの応答で障害が発生したかを正確に知ることができます。
それは「不安定」と見なされますか？私の意見では、いいえ。それはパイプラインの問題です。
繰り返しになりますが、トランザクション セマンティクスを備えた Redis 1.3.n は、この問題に完全に対処しています。
その問題以外に、非同期 (パイプライン) では、コネクタへの入力が過度に過負荷にならないようにするという大きな責任があります。JRedis パイプラインは、これを大幅に防止します (呼び出し元のスレッドを使用してネットワークに書き込みを行い、保留中の応答キューの入力負荷を自然に減衰させるため)。
しかし、まだテストを実行する必要があります。「本番」と言いましたよね? )) -- ボックスのサイズを調整し、フロント エンドのロード スレッドの数に上限を設けます。
また、マルチコア マシンで複数の JRedis パイプラインを実行しないことをお勧めする可能性もあります。既存の実装 (書き込みバッファーをチャンク化しない) では、同じサーバーに対して複数のパイプラインを実行することで、(帯域幅を最大限に利用し、スループットを最大化するという観点から) 効率を高める余地があります。1 つのパイプラインが書き込み用のバッファーの作成でビジー状態である間、もう 1 つのパイプラインは書き込みなどを行っています。ただし、これらの 2 つのパイプラインは (避けられない - これらはキューであり、何らかの形式の同期が発生する必要があることを覚えておいてください) および定期的なキャッシュの無効化により、互いに干渉します。 (最悪の場合、デキュー/エンキューごとに -- しかし、Doug Lea では信頼しています。) したがって、パイプライン A の平均レイテンシが (単独で) d1 に達すると、パイプ B にもヒットします。残念ながら、それらのうちの 2 つを同じコアで実行すると、新しいシステム全体のキャッシュ無効化期間が元のシステムの半分になるため、キャッシュ無効化が (平均で) 2 回発生します。だから自己破産です。ただし、負荷条件をテストし、予定されている運用展開プラットフォームでテストしてください。
于 2010-08-29T04:02:31.087 に答える