1.最初のRedisなぜ速いですか？
1.メモリに基づいて、ハードディスクIOの速度によって制限されません。
原因のCPU消費量を切り替える2.シングルスレッド、マルチスレッドを避け、彼らはロックの問題を考慮していない、ロックのロック解除操作が存在しない場合、発生するデッドロックのオーバーヘッドによる一切の性能はありません。
3.複数のI / O多重化モデル、非ブロックIO
複数のI / Oを選択し、世論調査の使用は、私が持っている1つ以上のストリームがある場合、ファイルディスクリプタ機能は同時に、現在のスレッドが遮断され、彼の空き時間に、複数のストリームのI / Oイベントを監視することができたモデルをされて多重化/ Oイベント、
プログラムは再びすべてのストリーム（ファイルディスクリプタは実際にイベントのストリームを送信していることのみ世論調査で）、および処理対応の流れの唯一の順番をポーリングしますので、このアプローチは、多くのを回避する状態を遮断状態から復帰し、役に立たない操作。
本明細書スレッド、マルチチャンネルIと多重化された手段を多重化、複数の要求の複数を指す/ O多重接続要求を複数の処理を単一のスレッド効率的に可能にする（ネットワークIOは時間を消費最小限）、
メモリ動作の範囲内であるRedisのメモリの高速動作及びデータは非常に高速であるが、主に高スループットで点より上のRedisを作成することによって、Redisのボトルネック性能なりません。
2.Redisなぜはシングルスレッドでありますか？
Redisのメモリ操作がボトルネック、CPUのRedisない、最も可能性のRedisのボトルネックマシンのメモリサイズや帯域幅に基づいているため。以来実装しやすいシングルスレッド、およびCPUがボトルネックになっていません、（すべての後に、複数のスレッドを使用して多くの問題が存在します）シングルスレッドプログラムを採用する論理的です。
言い換えれば、私はマルチスレッドを使用することはできませんので、シングルスレッドと低メンテナンスコストを実現する、プラスシングルスレッドパフォーマンスは、非常に高くなっているからです。
注ここで単一のスレッドでなく、私たちのネットワーク要求に対処するためのプロセスで唯一のスレッド、Redisのサーバーは、ランタイム確かに多くのスレッドよりも、例えば、方法で永続の子スレッドを実装することになります
Redisのボトルネック：
1.マシンのメモリサイズ、理由Redisのメモリ内のデータなので、どのくらいに依存してどのくらいのメモリに格納されたデータの量
2.ネットワーク帯域幅
Redisのクライアントは、次の4つのプロセスに分かれてのコマンドを実行します。
1）コマンドを送信します
2）コマンドキューイング
3）コマンド実行
4）リターン結果
前記1）4）と呼ばれるラウンドトリップ時間（RTT、ラウンドトリップ時間）。
クライアントとサーバーのRedisのは、異なるマシン上に展開することができます。
×2 /（300000×2/3）= 1300北京、例えば、クライアント、Redisの上海のサーバ、約1300キロの2直線距離は、RTT 1は、13ミリ秒（あたりの真空中の光の伝送速度=第30万キロ、光ファイバ）が2/3光速ここで想定されます、
次に、クライアントはわずか80回のコマンド、高いスループットと高い同時実行性のRedis反し約1秒程度で行うことができ、それは国のいずれかであることは、自身のRedisのサーバーを持って、その後、近くの訪問、またはパイプラインを使用します。
機構上記パイプ（パイプライン）は、この問題を改善することができ、一度のRedisにRTTによって送信されたセットのRedisコマンド、Redisのクライアント192に返送コマンドシーケンスのその後設定された実行結果をアセンブルする、画像ショーなしパイプラインは、nコマンドを使用して実行しました
全体のプロセスにはパイプラインRTT n回n回のコマンドモデルを取りません。
パイプラインは、新しい技術やメカニズムではありません、多くは技術的に使用されています。そしてRTTは、同じ部屋など、さまざまなネットワーク環境では異なるであろうと、同じマシンが速くなり、地域横断的な部屋が遅くなります。
Redisのは、リアルタイムに実行するコマンド我々はRedisのパフォーマンスのボトルネックがネットワークその引数である持っている理由、マイクロ秒レベルで通常です。
しかし、ほとんどの開発者は、現在最もRedisのクライアントはパイプラインをサポートし、クライアントのパイプラインに高レベルの言語を使用することを好みます。