これは、データ構造のタイプではありません
多くの記事は、Redisのは、実際には大きな曖昧さがあるで一般的に使用されるデータ型、の5種類をサポートしています、と言うだろう。Redisのバイナリデータに格納され、データ型のデータをバイトのみ妥当復号フォーマット後にそれらに応じていないバイトの配列（バイト[]）が、実際には、文字列、整数またはオブジェクトに変換することができこの場合には、データ型があります。
これは忘れてはなりません。何であれば、それはバイトの配列（バイト[]）に変換することができるように、Redisの中に格納することができます。あなたチューブの文字列、数値、オブジェクト、画像、サウンド、ビデオ、またはファイル、バイト配列が長くなります。
だから、文字列内のRedisは、文字列を参照していない、その1つの値のみの鍵と対応している、実際にはほとんどの単純なデータ構造のいずれかを表しています。ここで、キーと値のバイト配列であるが、典型的には、バイト配列、実際の必要に応じた値にキー列により変換されます。
ある場合には、例えば、値に関するいくつかの要件が存在するであろう、そうでない場合はエラーを減少するか、インクリメント動作は、対応するバイト配列値がデジタルジョブにデコードされなければなりません。
リストは、このデータ構造は、実際には、キー値の複数に対応することができる示し、値の間の連続的である、値の値が繰り返されてもよいです。
このデータ構造を設定し、キー値の対応する複数を表すことができ、その値は非連続ではなく、繰り返される値の値の間にあります。
このデータ構造をハッシュキーはキーと値のペアの対応する複数を表すことができ、その後、キーと値のペアの間の一般的なセンス配列は、名前の意味によってアクセスされるデータ構造ではなく、位置している、ではありませんセマンティクス。
このデータ構造を設定ソート、キー値が繰り返されることができないソート値、値の大きさとの間にある値の対応する複数を表すことができます。各値は、フロートに関連付けられた浮動小数点数は、スコアと呼ばれます。照合要素は次のとおりです。第1のスコアの並べ替え、値の順序で。
今、あなたはこれらの5つのデータ構造は、それに対応するコマンドは、あなたのための小さなケースであることを明確に理解を持っていると信じています。
クラスタおよびソリューションによって引き起こされる問題
クラスタの利点は、大容量、増加処理能力だけでなく、必要に応じて動的拡張、体積減少として、明らかです。しかし、また新たな問題を紹介します、少なくとも次の二つがあるでしょう。
まず、データ分布：データがどのノードに見えるように注意しなければならないときに格納されたデータが、どのノード上に配置されるべきです。第二に、データの移動：クラスター展開、新たに追加されたノードからノードにデータ、ノードを削除するクラスタボリューム縮小、移動する場所に関するノードデータ。
これらの質問の両方が共通にマッピングし、データ・ストレージ・ノード間の関係を記述する方法、あるています。問題は関係が各キーとすべてのクラスタノードとして進化確立する方法であるので、データは、キーの位置によって決定されるため。
除去ノードとノードを追加があるが、ノードのクラスタは、固定され、比較的少数です。しかし、クラスタ・ストレージ・キーは、完全にランダムな不規則かつ予測不可能である、マルチパンの数も非常に些細な。
これは、大学とそのすべての生徒との関係のようなものです。大学と学生が直接リンクされている場合、それは混乱取得する必要があります。現実には、プロが続く学部は、そこにあるすべての最初の、それらの間、彼らはいくつかの層を追加したことで、さらに、最終的にはクラスのグレードがあります。この4層マッピングした後、多くのさわやかの関係。
実際には、これは問題が層を追加することで解決されていないものを非常に重要な結論、この世界では何もないです。もしそうなら、それはその後、レイヤーを追加します。コンピュータは同じです。
ノードや層を追加することとの間のRedisのデータは、この層は、溝（スロット）と呼ばれ、なぜならハッシュスロットと呼ばれる溝主に関連するハッシュのれます。
最後に、スロットであり、スロットはデータを入れたノードに置く、となりました。スロット細分性の問題が解決され、より大きなに相当する粒子径は、データを移動することは容易です。ハッシュマッピングの問題は、データ配信を容易にするために、計算されたハッシュ値をキースロットが配置されている使用して、解決されます。
理解することができ、書籍を積まあなたの学習テーブルは、非常に混沌とした、非常に困難な特定の書籍を検索します。だから、テーブルの上にこれらのストレージボックス、その後、タイトルの長さに応じて、異なるストレージボックスにこれらの本を入れて、いくつかの大規模なストレージボックスを買いました。
これは、収納ボックスで、収納ボックスは、ブックでテーブルの上に、となります。この本はボックスと左を持ち上げ、移動させることは非常に簡単です。ブックを探している行に対応するボックスを見つけるためにも、タイトルの長さのカウント限り、非常に便利です。
実際に、私たちは一定のルールに従って、いくつかのボックスを購入し、何もしなかった箱の中に本を置きます。これは、単純な行為は、彼らは完全に状況の元の混乱を変更したことです。それは少し魔法ではありません。
クラスタのみ16,384スロット番号0から16383を有することができます。これらのスロットは要求していないクラスタの割り当て方法で、すべてのマスターノードに割り当てられます。あなたはマスターノードに割り当てられている番号のスロットを指定することができます。クラスタノードとスロットとの対応関係を記録します。
次に、ハッシュキー値を検索する必要があり、その後、残りの部分は、いくつかのキーに対応するスロットに入るように、16384を法。スロット= CRC16（キー）％16384 。
スロットの数が固定されているので、データ移動の問題が解決されるように、プロセスは、簡単であり、スロット単位でデータを移動させます。
それは、溝に対応する溝を計算し、データおよびノードがアップマップされるように、ノードが溝クラスタ内のクエリノードを格納されたマッピング関係を使用することができるように、データように、キーのハッシュ関数を用いて算出したハッシュ値配分の問題が解決されます。
私が言いたい、平均的な人だけのさまざまな技術を学ぶために、専門家は、この方向に沿って行くために方向のソリューションやアイデアを模索するために、技術の外にジャンプする方法についての詳細を気にすることをあるみかんあなたが欲しいものを見つけることができます答えます。
コマンド操作するには、クラスタの選択
限り、クライアントとして、クラスタ内のリンク・ノードを確立し、クラスタ内のすべてのノードに渡って情報を得ることができます。この情報は非常に便利ですので、また、相関関係ハッシュスロットと、すべてのノードの情報は、情報データは、クライアント側にキャッシュされますがあり得るでしょう。
最後にまでその要求ノードの後にキーを取得するように、クライアントは、任意のノードに要求を送信することができますか？実際には、クラスタノードの理論と主要クライアントのセットとの間のマッピングは、行に移動します。
クライアントバッファを使用することにより、溝、従ってハッシュキー溝に対応見出さので、クライアントは、キーのハッシュ値を計算するために、クラスタおよびハッシュ関数の同じ目的を達成する必要があり、再度16384を法と対応情報ノードは、ノードに対応するキーを見つけることができます。
そして、その上にリクエストを送信します。マッピング関係は、また、キーのノードと、キャッシュされた、鍵要求は、ノードが直接取得する次の時間とすることができるときに再計算することなく、再度、対応します。
常に理論と現実とのギャップは、クラスタは、変更されているクライアントのキャッシュを更新する時間がありませんでした。実際には、キーは、そのノードのアップになっていない、対応するノードに作られたキー要求が取得されます。このとき、ノードが行う方法をすべきですか？
このノードは、実際のキークライアントが一緒にキーノードに関する情報を、ここでは、もはや私の鍵を伝えることはできません、戻ってクライアントにデータを取得するためには、現在存在するノードに行くことができ、再びクライアント要求を聞かせて、 302リダイレクトをHTTPと同様。
これは実際に選択するだけでなく、哲学的な質問です。結果はRedisのクラスタが後者を選択したです。したがって、唯一の処理ノードは、独自のキーを持っている、キーはキー127.0.0.1:6381を-MOVEDリダイレクトエラーを返す必要がないことで、クライアントは戻って新しいノードに要求を送信します。
だから、選択肢が哲学である、また知恵です。これについては後で話します。のは、別の状況、およびこの問題のいくつかの類似点を見てみましょう。
Redisのコマンドは、私はこれらのマルチキーコマンドを呼び出す、などMGETなどの複数のキー、で一度あります。このマルチキーコマンド要求がノードに送信され、潜在的な問題があり、あなたが考えていないかどうか知りませんが、特定の複数のキーで、このコマンドであることをそれと同じノード上に配置されていますか？
、ノードのみリダイレクトエラーを返すことができ、より多くのキーは、いくつかの異なるノードに完全に配置することができる複数のノードに同じ鍵でない場合、それは二つのケースに分割され、その後、エラーをリダイレクト返さそれはそうRedisのクラスタがこのような状況をサポートしないことを選択し、非常に混沌となります。
複数のキーは、同じノード上にある場合は、理論的には、関係のRedisのバージョン、ライン上で自分自身をテストするための具体的な使用には何の問題、Redisのクラスタおよびサポートはありません。
このプロセスでは、我々は非常に重要なことは、関連するキーのグループが同じノードにマッピングされるようにすることは非常に必要であるが、これは複数のキーコマンドでより多くの価値を取得し、効率を向上させることができました。
そこで問題は、それらが同じノードに落ちるように、これらのキー名を再生する方法、である、彼らは、その後、残りを取る、あまりにも多くのトラブルをハッシュ値を計算する必要があります。もちろん、ない場合、Redisのは、それを超えると思うために私たちを支援してきました。
単純な推論が同じノード上に配置された2つのキーを取得するには、下に置くことができ、それらは同じハッシュ値でなければなりません。同じハッシュ値に、ハッシュ関数のような、文字列を渡す必要があります。私たちは、同じキーにならないよう、文字列の同一の二つに渡すことができ、そしてバックには、以前のデータが上書きされます。
ここでの問題は、我々は、ハッシュ値の計算に関与した文字列のキーとのカップリングにつながったハッシュ値を計算するために全体のキーを取っている、彼らは仕事から分離する必要があり、文字や参加は、ハッシュ値を計算することが鍵であることです文字列関連のではなく、同じ。
この原理に基づいて、Redisのは、ハッシュキーラベルと呼ばれ、私たちのためのソリューションを提供します。例を見て、{user1000} .following、{user1000 } .followersは、 私はあなたがハッシュ値が{と}キーに参加の間に配置されている文字列のみを用いて計算される、戸口を見ていると信じています。
これは、同じハッシュ値が、同じノード上に落ちることを保証します。しかし、キーが異なる場合、お互いに上書きされることはありません。関連するキー準までのグループにハッシュタグを使用して、問題が解決しそうリラックスして幸せです。
私はそれが技術の高速ハードウェアアルゴリズムを使用するために、むしろ非高速なハードウェアよりも、巧妙な奇抜で問題を解決することであり、あなたが発見したと信じています。これは、小さな小さな強力です。
最後に、その後、哲学的な選択肢について話しています。Redisのコアは、これらの構造の操作に関する一般的なデータ構造のキー/値のアクセス、およびデータの最速のスピードです。コアまたはコアとは無関係のが弱体化または無治療をドラッグします選択されているために、コアは、簡単で高速かつ安定していることを保証するために行われます。
実際には、幅と深さの前に、深さを選択のRedis。だから、自分のノードが鍵を持っていない処理しない、クラスタは、マルチキーコマンドをサポートしていません。だから1はすぐに、データ伝送の大規模な数を避け、マージするクラスタの内部には一方で、クライアントに応答することができます。
シングルスレッドモデル
各クラスタノードのRedisの唯一のスレッドがクライアントから送信されたすべての要求の受け入れと実施を担当しています。スレッドは、多くのソケット接続を管理できるように技術的には、のLinuxのepollの機能を使用して、多重I / Oを使用しました。
加えて、単一のスレッドを選択いくつかの理由があります
。、メモリの動作が高速のRedis、1である（10W + QPS）
2、である主伝送ネットワーク上で消費される全体的な時間
と、3マルチスレッドを使用して、マルチスレッドの同期が必要とされ、これは実装するために複雑になるであろう
4を、偶数メモリの動作時間を超えて時間をロック糸
5は、マルチスレッド・コンテキスト・スイッチは、しばしば多くのCPU時間が必要
6天然サポートアトミック操作をシングルスレッド、およびシングルスレッドコードを書くことがはるかに簡単があります
業務
私たちは皆知っている総務は、一緒に動作する複数のバンドルすることで、または実行されている（成功）、または何も（ロールバック）が実行されていません。Redisのも、トランザクションをサポートしていますが、することができ、何が欲しいの表情で、同じではありません。
Redisのトランザクションは、2つのステップに分けトランザクションの定義およびトランザクションを実行することができます。トランザクションを開くために、マルチコマンドを使用して、実行するすべてのコマンドを置くためのアップに配置されています。これは、トランザクションを定義します。今回は、このトランザクションを実行し破棄するか、トランザクションを放棄するコマンドを使用するには、execコマンドを使用して。
あなたは他のコマンドが運営するこれらのキーが取引をキャンセルさせて頂きます前に開始した場合、これらのキーを監視するために、watchコマンドを使用することができ、あなたが他の人を気にキー操作する必要はありません、あなたの事務の前で開始することをお勧めします。またこれらのキーの監視をキャンセルするunwatchコマンドを使用することができます。
：Redisのトランザクションは、次のような特徴がある
すべてのコマンドを実行していない、エラーが発生した場合、トランザクションの実装を開始する前に、1を
すべてのコマンドがによって中断されることなく、一連のワンタイム仕上がりに実行されることを保証するために、2、一度起動
実装プロセスエラーに遭遇した場合、3止まらない、実行を継続します
実装プロセスでエラーが発生したため、それはロールバックされません、4
それらを読んだ後、本当にあなたがこのトランザクションにそれを呼び出すことができ、言葉をお聞きしたいですか？明らかに、これはそれがさえアトミック性が保証されていないため、我々は通常、事務の考えるものではありません。私たちは、Redisのは、ロールバックをサポートしていないため、アトミックである保証することはできませんが、それはまた、サポートしない理由を与えます。
その理由は、ロールバックをサポートしません。
不適切な使用によって引き起こされるコマンドの失敗により、Redisのは、考える1を
2、のRedisは内部実装を維持するためにとてもシンプルで早いのが特長ですやる
3、Redisのもロールバックはすべての問題を解決することはできませんと信じて
ハハ、これはキングの用語は、それゆえ、あまり使用Redisの事務を思えません
パイプライン
クライアントの相互作用およびクラスタは、コマンド応答が戻ってきた後に、第2のコマンドが発行されるまで、クライアントによって送信されたシリアル化されたブロックは、待機する必要があり、これは往復時間に復帰されています。あなたは、1つのコマンドの多くは、すべてを持っている場合、それは非常に遅くなります。
Redisのは、それは、クライアントがサーバーの応答時間を待たずに、複数のコマンドを送信することができ、すべてのコマンドを介して送信され、その後、順次これらのコマンドへの応答の全てを受け取り、パイプライン技術を提供します。これは、効率を大幅に向上させるために多くの時間を節約できます。
スマートあなたは、複数のコマンドよりキーああ、マルチキー操作ではない、つまり、別の問題に気づいていないこと上記さて、その後の質問は、どのようにこのキーが同じノードの詳細であることを確認しますされますああ、ハハ、Redisのクラスタでは、パイプラインのサポートを打ち切りました。
しかし、クライアントは、アナログ実装することができ、コマンドは、同時に複数のノードへの複数の接続を使用して、その後、コマンド照合順序を送るリターンに応答してすべてのノードを待ち、ユーザコードに戻って送信されます。ああ、良いトラブルああ。
合意
理解することは簡単な契約Redisの下には、Redisのデータ転送フォーマットを知っています。
送信要求プロトコル：
*データパラメータCRLF CRLFのパラメーターパラメーターの数バイト$ CRLF CRLFパラメータデータ1 ... $ CRLFパラメータN Nは、バイト
実際に送信例えば、データ・セット名lixinjie、 ：
* 3 \ R \ nは$ 3 \ R \ NSET \ R \ N $ 4 \ R \ NNAME \ R \ nは$ 8 \のR \ nlixinjieの\ Rの\ n個の
プロトコルが応答受け入れ：
単一行の応答は、最初のバイトであるが+
エラーメッセージは、最初のバイトがあります -
整数、最初のバイトは次のようになります。
バッチ応答は、最初のバイトは$です
バッチ応答*バイトの複数最初に
例えば、
+ OKます\ r \ n
\ r個の\ nのに対して-ERR操作
：1000 \ r \ nの
$ 6 \ rを\ nfoobar \ rを\ nは
* 2 \ R \ nは$ 3 \ R \ nfoo \ R \ nは$ 3 \ R \ NBAR \ R \ nは
可視Redisのプロトコル設計が非常に簡単です。