Redis 分布式主从架构

Redis 集群设计的演变
Redis 从最早的集群设计，演变到现在，历经了三种集群状态：（1）主从复制；（2）哨兵集群；（3）分片集群。

1、分布式主从架构:
Master：主节点。负责对外提供数据的读写【写只能写 Master 节点】；
Slave：从节点。
（1）负责对外提供读的请求【默认不能写，可以开启写，但是没用。因为其他节点只和 Master 同步数据。所以不建议开启。】
（2）负责与主节点同步数据。
特点：主从节点上的数据都是一致的。连接任何一个节点实现读，默认写的操作只能连接主节点。
优点：实现了读写分离，分摊了读的压力负载。如果一个Redis 的 Slave 故障，其他 Redis 服务照常提供。
缺点：如果 Master 故障，整个集群不能对外提供写的操作，Master 没有 HA 机制。
Redis 的主从复制虽然解决了最早的单节点故障、以及并发量的问题，但是同时也引入了一个新的单点故障问题，即 Master 单点故障问题。
Redis 这种主从架构与 zookeeper 类似。但是也有差别：
（1）zookeeper 在这方面做得更好。一旦主节点故障，zookeeper中有重新选举的机制，follower节点会重新选举成新的主节点。其他节点会和新的主节点同步数据。而Redis的主从复制没有 HA机制。
（2）Redis的主从复制，slave只负责和Master同步数据。zookeeper 有“半数同步机制” ，超过半数的slave同步完成，则数据同步返回成功的状态。在性能与安全两者中做了衡量。

2、哨兵设计
思想：基于主从复制模式之上、封装了哨兵模式。如果Master出现故障，让Slave选举成新的Master。
实现：哨兵进程实现：
（1）必须发现Master故障
（2）必须负责重新选举新的Master

哨兵进程：每个哨兵负责监听所有的 Redis 节点和其他哨兵。
Q1: 为什么要监听所有 Redis 的节点？
监听Master是因为要发现Master是否故障；
监听Slave是为了选举一个新的Master；
Q2: 为什么要监听别的哨兵？
为了避免哨兵故障。

实现流程：
step1: 如果 Master 突然故障，有一个哨兵发现这个问题，这个哨兵立即通报给所有的哨兵。即：主观性故障【sdown】
step2: 当有一定个数的哨兵都通告 Master 故障了，整体认为Master 故障了。即：
客观性故障【odown】
step3: 所有哨兵根据每台Slave通信的健康状况以及Slave权重选举一个新的Master；
step4: 将其他所有的Slave的配置文件中的Master 切换为当前最新的 Master。

哨兵功能：
（1）集群监控：监控节点状态；
（2）消息通知：汇报节点状态；
（3）故障转移：实现Master重新选举；
（4）配置中心：实现配置同步

优点：简单方案解决了Master 的单点故障问题；
缺点：存储空间依旧只有一台机器。

3、分片集群设计
哨兵模式：解决了单点故障问题
分片模式：解决了单点故障以及资源不足的问题。

思想：将多个Redis小集群从逻辑上合并为一个大集群。每个小集群分摊一部分槽位【可以理解为一个范围】，对每一条 Redis 数据进行槽位计算。这条数据属于哪个槽位，就存储在对应槽位的小集群中。

分片规则：根据 Key 进行槽位计算。CRC16【key】 & 16383 = 0 ～ 16383.