Redis面试之单机、主从、哨兵、集群模式

一、单机模式
就是安装一个 redis 供业务方调用，没什么好说的，适用于对高可用要求低的场景。

优点：
部署简单，成本低，不需要同步数据

缺点：
1、可靠性差，宕机数据可能丢失
2、性能受限于CPU的处理能力，容量不能水平扩展

 
二、主从同步（复制）
不是单机了，至少得有两个redis服务器，将一台 redis 服务器当做主节点(master)，其他 redis 服务器作为主节点的从节点(slave)，可以将 master 的数据复制到其他 slave 节点（数据的复制是单向的，只能由主节点到从节点）。

同步原理：
第一次同步时，master 执行一次 bgsave 操作，并同时将后续修改操作记录到缓存中，完成后将 RDB 文件全量同步到 slave 节点。slave 将接收到的 RDB 文件加载到内存，然后再通知 mater 节点将这期间修改的操作记录再同步过来进行重放就完成了同步过程。后续的增量数据通过 AOF 日志同步即可，有点类似数据库的 binlog。

优点：
1、故障恢复：当主节点出现故障时，可以将从节点晋升为主节点继续提供服务
2、读写分离：主从同步可以实现读写分离，主节点写，从节点读，提高了服务器的负载能力
3、高可用基石：主从同步是哨兵和集群能实施的基础，是 Redis 高可用的基石

缺点：
1、本质上 master 节点仍是一个 redis 服务器，因此 master 节点的 写 和 存储 性能仍受到单机的限制
2、主节点宕机，需要人工干预将从节点晋升为主节点继续提供服务，整个过程较为繁琐

 
三、redis 哨兵
redis主从同步是保证其高可用的基石，它能尽量保证数据不丢失，同时也能实现读写分离，横向扩展系统的读负载。但是主从同步架构还有一个棘手的问题，就是如果主节点挂了，就要手动把一个从节点晋升为主节点，同时也需要把其他节点的主节点替换为新的主节点，整个过程复杂而且需要人工干预，效率低下。那么问题来了，有解决方案嘛？有，redis Sentinel（哨兵）机制啊。

啥是redis哨兵机制，它有啥用
它是一种能够自动完成故障发现和转移并通知应用方，从而实现真正的高可用的分布式架构。看下官方文档对于哨兵机制功能的描述：
（1）监控（Monitoring）：哨兵会不断检查主节点和从节点是否运作正常。
（2）自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
（3）配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
（4）通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

redis哨兵系统架构
如下图，主要包括两个部分：哨兵节点和数据节点。
哨兵节点：系统由若干个哨兵节点组成（至少3个哨兵节点）。哨兵节点就是一个特殊的 Redis 节点，只不过它是不存储数据的和仅支持部分命令。
数据节点：由主节点和从节点组成的数据节点。

ps：为啥哨兵节点至少3个？因为当主节点挂了，需要选择一个哨兵领导者来执行故障转移等操作，那这个哨兵领导者需要通过类似投票机制决定，需要至少半数的支持票才能成为领导者。试想一下，如果是两个哨兵，正好其中一个哨兵节点挂了，那剩下那个哨兵节点谁给它投票…大概就这个意思吧

redis 哨兵原理
主要包括四个部分，心跳机制、主观及客观下线、Sentinel 选举、故障转移
1、心跳机制
包含三个定时任务，主要用于维护当前系统最新的拓扑结构，比如说当前系统新加了一个节点，那哨兵节点就得发现它并与之建立连接啊。其中一个核心的定时任务是“每隔一秒，哨兵会每个主节点、从节点、以及其他Sentinel 节点发送 PING 命令，主要是为了监控各个节点的运行状态，为选举哨兵领导者做好准备。

2、主观下线、客观下线
（1）主观下线
心跳机制的核心定时任务是每隔一秒 Sentinel 节点会向其他数据节点发送 PING 命令，若超过 down-after-milliseconds 设定的时间还没有收到响应，那会对该节点做失败判定，这种行为叫主观下线。因为它只是当前一个节点的判定，可能存在误判。
（2）客观下线
当 Sentinel 节点判定一个主节点为主观下线后，则会通过 sentinel is-master-down-by-addr 命令询问其他 Sentinel 节点对该主节点的判定状态，当有超过 个 Sentinel 节点认为这个主节点有问题，这时该 Sentinel节点才会对这个有问题的主节点做客观下线判定。

Ps:客观下线只是针对主节点，如果主观下线的是其他非主节点，则不会进行后续的客观下线和故障转移操作。

3、Sentinel 选举
当一个 Sentinel 节点完成了主节点的客观下线后，能立刻进行故障转移操作吗？
不能，因为 Redis 的故障转移工作只需要一个 Sentinel 节点来完成，所以会有一个选举的过程，选举出来一个领导者来完成故障转移工作。Sentinel 选举主要流程如下：
每一个Sentinel 节点，如果其做了主观下线，那么它都有成为领导者，此时它会向其它的 Sentinel 节点发送 sentinel is-master-down-by-addr指令，要求其它Sentinel 节点将它设置为领导者。
收到命令的 Sentinel 节点，如果此时还没有同意过其他 Sentinel 节点（除了刚才发命令那个）发送的指令，那就会同意该请求，否则会拒绝。
如果想成为领导者的这个 Sentinel 节点发现自己得到的票数已超过Sentinel 节点集合的一半且超过预设阈值 quorum，那么它就会成为领导者。
选举过程中如果有多个 Sentinel 节点成为了领导者，那么过一段时间会重新选择，直到剩一个 Sentinel 节点成为领导者。
Ps：哨兵选举过程很快，一般情况下谁先完成客观下线就能成为领导者。

4、故障转移
当一个 Sentinel 节点成为领导者后，他就要进行故障转移了，具体步骤：
（1）在从节点列表中选一个节点作为新的主节点，选择策略如下：
过滤掉符合以下任意条件的非健康节点，主观下线、断线、5 秒内没有回复过 Sentinel 节点的 ping 响应、与主节点失联超过 down-after-milliseconds * 10秒
选择优先级最高的节点，不存在则继续
选择复制偏移量最大的节点（数据最完整），不存在则继续
选择 runid 最小的节点
（2）在新主节点上执行 slaveof no one指令，让其变成主节点
（3）向其他剩余从节点发送指令,让它们成为新主节点的从节点

优点：
主从模式的优点它都有，且可以自动故障转移不需要人工干预等，可用性更强

缺点：
单个节点的存储以及访问能力是有上限的，无法水平扩展

三、redis 集群
Redis 哨兵解决了故障转移问题，但是其本质上仍是单个节点存储数据，单节点性能有上限，无法水平扩展。而 Redis 集群则可以解决上面的问题。

原理
Redis 集群将数据分片存储，有多少个片就相当于有多少个 master 节点，master 节点提供写能力，master下面还有 slave 节点提供读能力，集群模式同时具备数据复制和故障自动转移功能。

1、如何分片
Redis 集群使用哈希槽分区算法。集群包含有16384个哈希槽（范围 0 -16383），这些哈希槽会被分成不同的部分，每个 Redis 节点只负责一部分哈希槽。在对数据操作时，先用 CRC16 算法对数据key进行计算并对16384取模（slot = CRC16(key)%16383），结果即为这个 Key-Value 要放入的槽位，根据该值去找到对应槽位所对应的 Redis 节点，这样就可以在这个节点上进行存取操作了。

那么问题来了，为什么是16384个槽位？
简单说就是 Redis 节点需要相互通信，通信是需要告诉对方所有槽位的信息，槽越多通信是携带的数据量越大（心跳包大小），一般情况下 Redis 的集群主节点数不可能超过1000个（大于1000个也会导致网络拥堵），用16384个槽位够用了，此时心跳包大小是16384÷8÷1024=2kb，当槽位达到最大65536时，心跳包是65536÷8÷1024=8kb，性价比低也没必要。

2、如何对数据读写
读写分离：写请求分配给master节点，读请求分配给slave节点，数据复制从master到slave。

3、如何水平扩展
举栗：假设有三个 master 节点，此时槽被分为三部分，假设其分别是0–7000，7001–12000、12001–16383。
现在因为需求要新增一个 master 节点，那么将是四个节点来划分16384个槽，此时槽位需重新分配，数据需重新迁移，但服务不需要下线。重新分片由 Redis 内部管理软件redis-trib 执行，其提供了重新分片操作的所有命令。

4、如何自动故障转移
和哨兵原理一样，假设图里红色的节点发生故障，此时 master3 下的从节点会通过选举产生一个新 master 来替换原来的故障 master。