Redisパーティション

2949 ワード

パーティションは私の理解では、もともと1つのRedisがすべてのget/setリクエストを処理していたが、今では複数のRedisインスタンスでget/setリクエストを分担している.
  • なぜパーティションを使用するのですか?
  • 拡張
  • 計算能力を向上させ、帯域幅
  • を向上させる.

    パーティション基準

  • レンジパーティションは、異なるレンジのオブジェクトを異なるRedisインスタンスにマッピングすることである.例えば、ユーザIDは0から10000までR 0に格納され、ユーザIDは10001から20000までR 1に格納される.これは実行可能な案であり、多くの人が使用しています.しかし、このスキームには、redisインスタンスへのデータのマッピング関係を格納するテーブルを作成する必要があるという欠点もあります.このテーブルは非常に慎重に維持され、各クラスのオブジェクトにマッピング関係を確立する必要があるため、redis範囲パーティションは通常、他のパーティションスキームよりも効率的に実行されません.
  • Hashパーティション
  • 1.         (  crc32 )           。 : foobar,   crc32(foobar)        93024922。
    2.              ,     0 3   ,       key   4 Redis       。93024922 % 4    2,    foobar       2 Redis  。 R2   :          ,               %
    

    パーティションの実装スキーム

  • クライアントパーティションは、クライアント自身がKeyをどのインスタンスに格納するかを決定し、どのインスタンスに行って
  • を取得する.
  • エージェントパーティションクライアントはエージェントに依存し、エージェントはどのノードにデータを書くか、またはデータを読むかを決定する.エージェントは、パーティション化ルールに従って要求されるRedisインスタンスを決定し、Redisの応答結果に基づいてクライアントに返す.redisとmemcachedのエージェント実装の1つはTwemproxy
  • である.
  • は、ルーティングクライアントが任意のredisインスタンスをランダムに要求することを問合せ、その後、Redisによって要求を正しいRedisノード
  • に転送する.

    パーティション化の欠点

  • に関連する複数のkeyの動作は、通常サポートされない.たとえば、2つの集合に交差を求めることはできません.複数のKeyのトランザクション
  • バックアップ/リカバリの複雑化
  • パーティションで使用する粒度はkeyであり、zset機能は
  • に制限される.
  • 拡張および縮小動作複雑
  • キャッシュと永続化パーティションの違いとして使用


    使用経路が異なるRedisパーティションの実装は少し異なる.Redisを永続化ストレージとする場合、keyは同じRedisインスタンスに厳格にマッピングされる必要があります.Redisをキャッシュとして使用すると、Redisのノードの1つが使用できなくても、データが失われてもMysqlなどのデータベースからデータを引き出し、任意のルールでマッピングを変更することで、一貫性のあるHashアルゴリズムを使用するなど、システムの高可用性を向上させることができます.この方法では、keyの優先ノードが使用できない場合に他のノードに切り替えることができます.同様に、新しいノードを追加すると、すぐに新しいkeyがこの新しいノードに割り当てられます.
  • 重要な結論は以下の通りである.
  • Redisがキャッシュとして使用される場合、一貫性ハッシュを使用して動的拡張容量縮小が実現される.
  • Redisが永続化ストレージとして使用される場合、ノードの数が決定されると変化しない固定keys-to-nodesマッピング関係を使用する必要があります.そうでない場合(すなわち、Redisノードが動的に変化する必要がある場合)は、実行時にデータの再バランスが可能なシステムを使用する必要があるが、現在はRedisクラスタのみが可能である-Redisクラスタは2015.4.1.


  • プリディビジョン


    Redisを永続化する場合、一般的には時間が経つにつれてデータストレージの要件が変化します.今日は10個のRedisノードで十分かもしれませんが、明日は50個のノードに増やす必要があるかもしれません.これは面倒です.今後の拡張を防止するには、最初から多くのインスタンスを起動することが望ましい.サーバが1台しかない場合でも、最初からRedisを分散的に実行させ、パーティションを使用して同じサーバ上で複数のインスタンス(擬似クラスタ)を起動することができます.最初から32または64のインスタンスのようないくつかのRedisインスタンスを複数設定するのは、多くのユーザーにとって面倒かもしれませんが、長期的にはこのような犠牲を払う価値があります.このように、データが増加し続け、より多くのRedisサーバが必要になった場合、Redisインスタンスを1つのサービスから別のサーバに移行するだけです(再パーティション化の問題を考慮する必要はありません).別のサーバを追加すると、Redisインスタンスの半分を最初のマシンから2番目のマシンに移行する必要があります.おおよその手順は次のとおりです.
  • は、空のインスタンスnewを別のマシン上で起動する.
  • newをあなたのソースインスタンス(拡張するインスタンス)のスレーブノードとして構成します.
  • クライアント
  • を閉じる.
  • クライアントの構成(新しいマシンに接続されたIp)
  • を変更する.
  • 主ノードnewを主ノードSLAVEOF NO ONE
  • に設定.
  • クライアント
  • を再起動する.
  • ソースインスタンス
  • を閉じる

    パーティションのオプション

  • 優先Redis Cluster
  • ツイッターオープンソースのエージェントtwemproxy
  • を使用
  • コンシステンシハッシュをサポートするクライアント
  • を使用する