Redis集群模式有以下三种：主从模式、哨兵模式、Cluster模式。如果不明白重点看这个图文： 简介https://cdn.modb.pro/db/324485

主从模式

解决的问题：提高读写性能；提供redis快速恢复（手动）
主从模式最起码需要2台机器：一主一从
工作机制
当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

  1. # slaveof <masterip> <masterport>
  2. # 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135，端口是6379。 
  3. replicaof 1192.168.10.135 6379

salve挂了，不影响master读写。master挂了，不影响salve读。master挂了，要手动启动master或选择某一个salve作为master启动。
主从模式拓扑有以下三种：

  • 一主一从：一般来说这个从是作为备份机器，提供快速故障转移的。
  • 一主多从：利用多个节点进行读写分离，减轻主的压力。同时可以将比较耗时的命令在从服务器上进行。

  • 树状主从：解决从机过多时，主节点写命令的多次发送从而过度消耗网络带宽的问题。由图中可知，A是BC的主，而从机B又是DE的主。image.png

    哨兵模式

    解决的问题：解决了主从模式，从不会自动升级为主的问题。
    哨兵（Sentinel）模式是Redis高可用的解决方案：
    由一个或多个Sentinel实例组成的Sentinel集群，可以监控一个或多个主和多个从服务器。哨兵模式下，当主下线了，会自动挑选一个从作为主服务器。
    sentinel的默认配置在sentinel.conf，命令行是redis-sentinel
    redis的默认配置在redis.conf，命令行是redis-cli
    哨兵模式最起码需要5台机器：一主一从，三个sentinel，因为哨兵选举需要过半机制，如果只有一个sentinel，那么sentinel挂了，就无法进行故障转移了。如果sentinel是偶数，容易出现脑裂，选举不成功。
    如果不考虑高可用，仅仅需要主从转移故障，可以只配置一个sentinel。
    哨兵模式监控的原理

  • 每个Sentinel以每秒钟一次的频率，向它所有的主服务器、从服务器 以及其他Sentinel实例 发送一个PING 命令。

  • 如果一个实例（instance）距离最后一次有效回复PING命令的时间超过down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel标记为 主观下线。
  • 如果一个主服务器 被标记为主观下线，那么正在监视这个主服务器的所有 Sentinel 节点，要以每秒一次的频率确认该主服务器是否的确进入了主观下线 状态。

  • 如果一个 主服务器 被标记为 主观下线，并且有足够数量的Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个该主服务器被标记为 客观下线。

    Cluster模式

    通过数据分片的方式来进行数据共享问题，同时提供数据复制和故障转移功能。
    分片
    集群的键空间被分割为16384个slots（即hash槽），扩容缩容的时候都要对槽进行再分配，如果扩容的节点没有分配槽，则该节点不可用，在扩容缩容的时候，不需要停机，但是需要分配槽，分配槽过程中会迁移数据，涉及到的节点不可用。
    扩容：redis-cli —cluster add-node
    缩容：redis-cli —cluster del-node
    故障检测流程

  • 1、集群中的每个节点都会定期地(每秒)向集群中的其他节点发送PING消息 如果在一定时间内(cluster-node-timeout)，发送ping的节点A没有收到某节点B的pong回应，则A将B标识为pfail。

  • 2、A在后续发送ping时，会带上B的pfail信息， 通知给其他节点。
  • 3、如果B被标记为pfail的个数大于集群主节点个数的一半(N/2 + 1)时，B会被标记为fail，A向整个集群 广播，该节点已经下线。
  • 4、其他节点收到广播，标记B为fail。

RedisCluster失效的判定:
1、集群中半数以上的主节点都宕机(无法投票)
2、宕机的主节点的从节点也宕机了(slot槽分配不连续)
故障转移 和哨兵的故障转移流程一致。

三者对比

  • 主从1.0：从服务器拥有主的完整数据备份，主宕机，该模式不会自动故障转移，只能依靠人工选择某台从作为主。（至少两台机：一主一从）
  • 哨兵2.0：基于主从，在主从上加sentinel集群监控主从的状态，会自动故障转移。（至少5台机：一主一从+3个sentinel（2N+1个sentinel，因为过半选举，防止脑裂））
  • 主从和哨兵都没有解决数据量多的问题。
  • 集群模式3.0，数据分片存储，并且能自动故障转移。（至少6台机：3主3从，也要设置成2N+1，过半选举，防止脑裂）