クラスタの原理
データ同期およびクラスタのフォールトトレランス:主に私たちは二つの問題を解決する必要があるシステムのクラスタを確立します。
ナイーブプログラム
シンプルで粗溶液は、複数の同一のRedisのサービスを展開し、次に共有し、サービスの状態を監視するために圧力バランスをロードすることです。このアプローチの利点は、フォールトトレランスは、クラスタ全体がまだ使用可能になります限り生存があるので、シンプルであるということです。しかし、その問題は、これらのRedisのサービスは、データ同期の大量につながるが、パフォーマンスと安定性に影響するとき、そのデータに一貫性があることを確認することです。
Redisのクラスタリングソリューション
Redisのクラスタ方式は、分割統治の考えに基づいています。キー異なるデータは互いに独立していながら、Redisのデータは、キー値に格納されています。したがって、特定の規則に従ってキーが複数のパーティションに分割することができ、異なるノード上の異なるパーティションに格納されたデータ。本実施形態では、ハッシュテーブルのデータ構造の構造と同様です。Redisのクラスタを達成するために、ハッシング・アルゴリズムを用いて(式があるCRC16(Key) mod 16383
)キーは、0から16,383までの範囲の整数にマッピング。こうして格納されたデータキー値の数に対応する整数は、例えばストレージ抽象化に対応する整数は、スロット(スロット)と呼ばれます。各Redisのクラスタノードは-正確マスターノードが何であるかを言う-スロットの範囲を担当して、クラスタ内のすべてのノードは、0〜16383のスロットの全範囲をカバーします。
任意のコンピュータの問題は、中間層を追加することによって解決することができると言われています。コンセプトはとても一つのスロットです。これは、操作の難しさの伸縮を簡素化し、データとノードの間にあります。固定されたアルゴリズムによって、リレーショナルデータをマッピングし、溝が完了し、メンテナンスを必要としない、唯一のノード自体は、マッピング関係と溝を維持します。
奴隷
上記のプログラムは、唯一のパフォーマンスのスケーラビリティの問題を解決し、耐障害性とクラスタリングは改善しませんでした。フォールトトレランス機能は、一般的にいくつかのバックアップを使用して改善/冗長性を意味します。ノードのスロットの特定の数の責任は、マスターノードと呼ばれます。スレーブノードと呼ばれる - クラスタの安定性を高めるために、各マスター・ノードは、バックアップノードの数を構成することができます。スレーブノードは、一般に、マスタノードがダウンした場合、マスターノードを置き換える、コールドバックアップマスタノードとしてデータが記憶されています。データアクセス圧力が比較的大きいのいくつかでは、スレーブノードは、データを読み取るための機能を提供することができますが、データのリアルタイムのスレーブノードは、わずかに悪いになります。動作は、マスタノードを介してデータを書き込むことができます。
要求をリダイレクト
ノードが責任の独自の領域内ではないキーの対応するスロット移動、リダイレクトエラーがデータにアクセスするために正しいノードにクライアントに通知するために返された場合のRedisは、キーにコマンドを受信した場合。
リダイレクトエラーが頻繁に発生する場合は、アクセスの性能に影響を与えるにバインドされています。それは谷する公開鍵アルゴリズムから一定のマッピングであるため、クライアントは、ノードに内部スロットとの間のマッピングを維持することができる、あなたはエラーをリダイレクト削減、データにアクセスするためのキースロットによって自分自身を計算し、正しいノードを見つけることができます。現在、Redisのクライアントは、ほとんどの開発言語は、この戦略を実装します。このアドレスhttps://redis.io/clientsは Redisのクライアント言語の主流を見ることができます。
ノード間通信
依然としてノード状態情報を同期させるために他の各ノードと通信する必要が互いに独立して異なるノードに記憶されたデータ、ものの。常時通信ノードとの間で情報を交換する、P2Pプロトコルを使用してゴシップRedisのクラスタは、すべてのノードの最終的な状態は、合意に達します。ゴシップ共通メッセージは、次のカテゴリのとおりです。
- pingメッセージ:各ノードは、継続的に他のノードにpingメッセージを開始し、ノード線はノード状態情報を切り替えるかどうかを検出します。
- メッセージをピンポン:応答メッセージがpingを受信したときに、メッセージを満たしています。
- ニュースを満たしています。新しいノードがメッセージを結合します。
- ノードオフラインメッセージ:メッセージを失敗します。
- メッセージを忘れる:ノードメッセージを忘れて、そのノードをオフライン。このコマンドは、すべてのノード、またはノードの60秒以内に実行されなければならない60秒以上のメッセージ交換後の再係合します。練習は、ノードをオフラインで動作させるために忘れて直接使用することをお勧めしません。
ノードをオフライン
ノードの問題は、マスターノードの大多数は、ノードが実際に利用不可能であると考えて広めるためにいくつかの時間がかかる場合は、ノードは、組立ラインオフ本物のマークをマークすることができます。二つの側面を含むRedisのクラスタノードをオフライン、:主観オフライン(pfail)と客観オフライン(失敗)。
- 主観オフライン:クラスタ・ノード・タイムアウト時間内にノードAと通信ノードB(ピンポンメッセージ)が失敗した場合、ノードBが利用できないことを、ノードAは、主観的にオフラインとしてマークされ、そして他にステータスメッセージを伝播されますノード。
- 目的オフライン:ノードがオフライン主観的なクラスタ内のマスターノードのほとんどをマークされている場合は、目的は組立ラインのプロセスをオフトリガ、本当にオフラインノードをマーク。
回復
マスターノードスロット客観オフラインを保持した後、クラスタは、スレーブノードからそれを置き換えるために推進し、マスターノードを選出します。スレーブノードを選択するように投票アルゴリズム - 選挙を使用してのRedisクラスター。スレーブノードの後マスターノードに昇格するためには、マスタノードのほとんどを含むマスターノードの故障など、投票しなければなりません。フェールオーバーを実行するには、少なくとも2つの主要なノードを持っている必要があり、3マスタから3のクラスタサイズを想定しています。展開は、同じサーバー上の2つの主要なノードを展開する場合は、サーバーがダウンしている、残念ながらクラスタでは、フェールオーバーを実行することはできません。
デフォルトでは、Redisのクラスタマスターノードは、ノード・スロットの数は、クラスタ全体が利用できないの原因ではないがあること、がある場合に使用できません。マスターノードに障害が発生した場合には、このとき、クラスタ全体が使用不能状態にある、フェイルオーバーです。これはいくつかのビジネスのために、それは耐え難いです。あなたはすることができ、クラスタ-必要-フルカバレッジ設定がNOに構成されるように、それは他のノードへのアクセスには影響を与えない溝を、関連するデータへのアクセスの失敗に責任があるとき、それが唯一のマスターノードに影響します。
クラスタを構築します
新しいノードを開始します
クラスタモードを有効にするには、Redisの設定ファイルを変更します。
# 开启集群模式
cluster-enabled yes
# 节点超时时间,单位毫秒
cluster-node-timeout 15000
# 集群节点信息文件
cluster-config-file "nodes-6379.conf"
次に、新しいノードを開始します。
クラスタノードを満たすためにメッセージを送ります
クライアントがコマンドを開始使ってcluster <ip> <port>
、ノードは、新しいノードの指定されたIPとポートがクラスタに参加満たすためにメッセージを送信します。
分配溝
上一步执行完后我们得到的是一个还没有负责任何槽的“空”集群。为了使集群可用,我们需要将16384个槽都分配到master节点数。
在客户端执行cluster add addslots {<a>...<b>}
命令,将<a>
~<b>
范围的槽都分配给当前客户端所连接的节点。将所有的槽都分配给master节点后,执行cluster nodes
命令,查看各个节点负责的槽,以及节点的ID。
接下来还需要分配slave节点。使用客户端连接待分配的slave节点,执行cluster replicate <nodeId>
命令,将该节点分配为<nodeId>
指定的master节点的备份。
使用命令直接创建集群
在Redis 5版本中redis-cli
客户端新增了集群操作命令。
如下所示,直接使用命令创建一个3主3从的集群:
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \
127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
--cluster-replicas 1
如果你用的是旧版本的Redis,可以使用官方提供的redis-trib.rb
脚本来创建集群:
./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \
127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
集群伸缩
扩容
扩容操作与创建集群操作类似,不同的在于最后一步是将槽从已有的节点迁移到新节点。
- 启动新节点:同创建集群。
- 将新节点加入到集群:使用
redis-cli --cluster add-node
命令将新节点加入集群(内部使用meet消息实现)。 - 迁移槽和数据:添加新节点后,需要将一些槽和数据从旧节点迁移到新节点。使用命令
redis-cli --cluster reshard
进行槽迁移操作。
收缩
为了安全删除节点,Redis集群只能下线没有负责槽的节点。因此如果要下线有负责槽的master节点,则需要先将它负责的槽迁移到其他节点。
- 迁移槽。使用命令
redis-cli --cluster reshard
将待删除节点的槽都迁移到其他节点。 - 忘记节点。使用命令
redis-cli --cluster del-node
删除节点(内部使用forget消息实现)。
集群配置工具
あなたのRedis-cliのバージョンが5未満である場合は、上記のコマンドを実行するためにRedisの-trib.rbスクリプトを使用することができます。クリックして、ここで表示するredis-cli
と、redis-trib.rb
運転指令クラスタ。
持久化
RDBとAOF Redisの永続化戦略の2種類があります。
ピットのRDBの永続性
RDBは、神のピットを永続性:
- でも設定
save ""
RDBを閉じようと、それでもRDBを引き起こす可能性が永続あります。 - ノードから(例えば、新しいノードから)全額をコピーし、マスターノードのトリガーは、RDB RDB永続ファイルを生成しました。RDBは、そのノードにファイルを送信してください。最後に、スレーブノードとマスターノードは、対応するファイルRDBを持っています。
- シャットダウンの実装は、AOFを開けない場合、また、RDBの永続性を誘発します。
- 関係なく、セーブセット方法の、限りRDBファイルが存在しているとして、ときRedisのは、ファイルをロードするために開始します。
結果:
- あなたはRDBの永続性(永続性とAOF)を閉じる場合は、Redisのが再起動したとき、それはコピー時に保存された最後のロードまたはノードの全額からシャットダウンRDBファイルを実行します。そして、このRDBファイルには、長い時代遅れのデータである可能性が高いです。
- クラスタモードの下では、再起動後やRedisのRDBからデータを回復する構成で無読み取り、クラスタ設定ファイルノード、場合に、ファイルの別々のマスターキー溝として自分自身を標識し、RDBのデータから回復し、対応する占有、これは、追加することができない他のクラスタ・ノードにつながります。