主要鉄道からJavaアーキテクチャ--Redis /センチネル/クラスタ/スロットアーキテクチャコメント

複数のRedisのマスター

そして、MySQLと同じ理由のマスタースレーブのレプリケーション、書かれたのRedisの読み込み速度が特に速いですが、また圧力を読んでいるが、特に大きいです。読み取り圧力を共有するために、Redisのマスター - スレーブレプリケーションをサポートする、Redisのマスター - スレーブ構成は、マルチマスターまたはカスケード構造から採用することができる、Redisのマスターはいかの複製に係る増分同期および同期の合計量の合計量に分割することができます。

古典的なアーキテクチャは、このようなモノマーのRedisである：2からマスターモデルは別個読み出し及び書き込みを達成します。

• マスターノード：書き込みサービスを提供
• スレーブノード：読み取るサービスを提供する
  
  マスタ・スレーブ複製プロセス：
  ちょうど接続時間からのマスタ同期の全額、完全同期の終了後に、増分同期。もちろん、必要に応じて、同期の全額を開始するために、任意の時点でスレーブ。Redisの戦略は、いずれの場合にも、第1の同期スレーブの完全な量を必要とする、そのような失敗として、増分同期にしようとしています。
  
  ディスクのいかなるコピー：
  マスターが直接RDBメモリ内に作成されていないし、その後ではない床の独自のローカルディスクには、スレーブに送信されました。
  

Redisのセンチネル

センチネル（Sentinelは）のRedis、センチネルは1を監視することができますされた高可用性ソリューションのためのマスターRedisのクラスタの状態を監視するためのツールである以上は、マスター・サービスとサービスから、これらすべてのマスター・サービスをRedisの、時にマスター・サービスのダウンタイムマスターへのこのマスターの下でサービスからのアップグレード後にそれが仕事までマスターを交換する必要があります。

マスターマルチスレーブの欠点があります：マスターノードがハングアップすると、スレーブノードが書かれたサービスを提供することができません。

为了保证Redis的可用性，就引入了哨兵。哨兵可以是一个也可以是多个，这里介绍一个经典的一主二从三哨兵的场景：

这里每一个哨兵都会对master和slave做一个监控，现在如果master挂掉：

哨兵1检测到了，但是此时不能去切换这个master，因为网络可能会有波动，哨兵1检测master挂掉，但是如果仅仅是网络波动，也会表明是挂掉的，在网络波动里，哨兵2和哨兵3也许检测到master仍然存活，所以仅仅靠一个哨兵是不能决定master存活与否的。

这里就引入了少数服从多数的机制，如果哨兵里面一半以上检测到了master挂掉，那么就开始切换master。

现在就需要选举learder，也是通过哨兵来进行少数服从多数的投票，来将slave变成master。新上任的master需要和剩下的slave进行同步。

最后当前任master恢复后，会成为slave，并与现任master同步。

tips:

1. 所以，哨兵的部署一定要分布式的部署在不同的节点，其健壮性才能更高。
2. 哨兵模式其实也是一种集群，他能够提高读请求的并发，但是容错方面可能会有一些问题，比如master同步数据给slave的时候，这其实是异步复制吧，这个时候master挂了，那么slave上的数据就没有master新，数据同步需要时间的，1-2秒的数据会丢失。master恢复并转换成slave后，新数据则丢失。

Redis集群

下面是三主三从的模式：

特点

• 每个节点知道彼此之间的关系，也会知道自己的角色，当然他们也会知道自己存在与一个集群环境中，他们彼此之间可以交互和通信，比如ping pong。那么这些关系都会保存到某个配置文件中，每个节点都有，这个我们在搭建的时候会做配置的。
• 客户端要和集群建立连接的话，只需要和其中一个建立关系就行。
• 某个节点挂了，也是通过超过半数的节点来进行的检测，客观下线后主从切换，和我们之前在哨兵模式中提到的是一个道理。

そこに多くのRedisのスロット、スロットは、データを格納するために、ノードと呼ばれることができます。
データが格納されているかを決定またはノードのRedisからRedisのノードを読み取るためのハッシュ関数によってRedisの。各ノードは、複数のスロット、すなわち、これらの溝に格納されたデータを含みます。下図のように：