はじめは、
NoSQLのソフトウェアの良い代表としてのRedis Redisのは、起動しやすく、使用することですが、オンラインそれを十分に活用することは容易ではないだろうが、ますます人気が高まっています。Redisのクラスタは、追加のクライアントのサポートを必要としない、と今基本的に、適切なクライアントは実際には、これらの事を行うには、クライアントがこれらの事を行うことができますし、何かどうかのRedisセンチネルが付属し、高可用性とスケーラビリティをRedisの不適切な、それはメンテナンスが特に困難となります。クライアントにサービスを提供し、クライアントとサーバーのRedisの物質の層を追加するには、バックエンドプロキシRedisの実装の詳細のRedisのを遮蔽する、理想的なソリューションとなっている間ので、Redisのは、高可用性とスケーラビリティの問題に最適な解決策になることができ、しばらくRedisの導入剤はまた、メンテナンスが容易になります。本論文では、エージェントpredixyを導入することである前に、彼らはユニークで、いくつかの人気のRedisの薬がありました。次に、我々は次のエージェントを比較する必要があります。
エージェントに紹介
詳細な機能の比較
簡単に言えばを、predixyサポートの両方のRedis Sentinelはまた、Redisのクラスタをサポート
モニター、元の完全に機能的な等価物のRedis用のセンチネルRedisのRedisの後方のグループ
モニターは、いくつかの機能制限の後センチネルRedisのRedisの複数組の
クラスタのRedisの後端、クラスタRedisの機能は全く同じ
性能
プロキシRedisのよう高いパフォーマンスは、我々は簡単な評価、テスト・プラットフォームおよび各機関の特定のバージョン情報であることを要する4つの薬剤上記のパフォーマンスをテストするために必須の要件である、次のとおりです。
展開をRedisの：
ねじSET / GETの試験は
、本明細書〜4は、薬剤が単一のスレッド（以下同様）下で動作するスレッド意味、デフォルトの同時クライアント接続50、ベンチマークのRedisそれぞれ送信するように接続された各応答が発行されたコマンドの後に受信します次のコマンドを実行します。これは、多くのオンライン実際の場面です。
テストコマンド：
$ Redisの-ベンチマーク-t -p xxxのSET、GET -r -n 3000 1000000 -d xxxの
テスト結果：
結果は：
他の2以上のスループットで、パフォーマンスpredixy大幅に先駆け、他の3つのエージェントの4つの物質の規則的な配列、が、再びtwemproxy大きなリード、2つの未満CODIS 512内のデータの残量データが512よりも大きい場合、ケルベロスにつながるCODISとき少し先にケルベロス、そして成長しています。データの全体量が16キロバイトに到達するときは、原因のRedis-ベンチマーク自体がボトルネック、predixyなるとほぼ同じSET結果をtwemproxy。
遅延では、言語の問題のためのCODIS、フォローアップのテストは、あまりにも、他の3つのエージェントより大きくなっています。
シングルスレッドPIPELINE SET / GETテスト
いくつかのシナリオの下で、クライアントが開始するかもしれないの必要性を要求することができる要求パイプラインの要求がより一緒にRedisの場合は、その後、それがパフォーマンスを大幅に向上させるだろう、要求に対処する上で何回ものRedis。クライアントが動作するようにどのように複数の代理店を送信するために私たちを尋ねられたとき、テストの現在のラウンドを見てみましょうか？まだRedisのベンチマーク同時接続50、20が、送信されたコマンド。
テストコマンド：
$ Redisの-ベンチマーク-t -p xxxのSET、GET -r -n 3000 20 5000000 -P -d xxxの
試験結果：
結果があることを示す：
スループットで、Redisのベンチマークをパイプライン20のコマンドの後に、各エージェントすべてのスループットが急騰しました。データ量が2K Redisのベンチマーク自体よりも大きいpredixyは、となっているので、predixyははるか先他の三つの、Yiqijuechenあり、かつpredixyパフォーマンスおよび他の薬剤ときGET 4Kデータの数がほとんどを見ることが最後ボトルネック。テストの最後のラウンドで遅れて他の3つのエージェントは、テストの現在のラウンドではるかに優れたケルベロスtwemproxyとCODISを表示するために始めたが、ケルベロスはパフォーマンスで大量のデータが急速に悪化まだあります。パフォーマンスをテストする現在のラウンドでtwemproxyとCODISはほぼ等しいです。
遅延に、CODISパフォーマンスの低下に固有の問題、データ少量の他の三つの差が小さい場合、そのデータ量が512を超える場合、predixyは明らかな利点を示しました。
PIPELINE SET / GETテストをデュアルスレッド
twemproxyは、マルチスレッドをサポートしていませんので、したがって、マルチスレッドテストに参加していないtwemproxy、シングルスレッド、マルチスレッドテストに亘って測定し、今我々が開始します。我々は、単一のコマンドのパフォーマンスを測定する場合は、アカウントへのRedis-ベンチマーク自体を取ることのRedis-ベンチマークはボトルネックは、各エージェントのパフォーマンスをより明示的なショーすることができない可能性があることを、直接私たちは、マルチスレッド・エージェントでは、シングルスレッドプログラムでありますパイプラインテストは、さえ最後のラウンド、50の同時接続、最初の送信20のコマンドとして行ってきました。
テストコマンド：
$ Redisの-ベンチマーク-t -p xxxのSET、GET -r -n 3000 20 10000000 -P -d xxxの
テスト結果：
説明結果：
一貫性の全体的な傾向とシングルスレッドのパイプラインのテストの第二ラウンドは、predixyまだテストのこのラウンドでリードを奪ったが、ケルベロスとpredixy先行CODISの初めに、ケルベロスとpredixyはあまり違いはありませんでした。しかし、データの量が増加すると、ケルベロスは再びさらに悪化CODISより1Kを超え、急激な減少のパフォーマンスの問題を示しました。
結論
比較関数には、ネイティブRedisのシーンの使用に完全に適用することができ、他の3つのエージェントに比べてより包括的なpredixy。パフォーマンスでは、predixyテストの各ラウンドで大差でリードしています。次のように機関の概要は以下のとおりです。
predixy：全機能、単一のマスタのRedisから、Redisのクラスタをも使用することができるいずれかの、優れた性能。
twemproxy：可用性に依存一貫したハッシュ、キャッシュ内の唯一のシナリオ、メモリNAを使用して、メディアのパフォーマンス。
CODIS：クラスタが使用適用Redisのを、一般的にパフォーマンス。
ケルベロス：使用Redisのクラスタに適した、パイプライン内の許容可能な性能とデータの使用量が少ない、またはパフォーマンスの低下。