Redis高可用：持久化、复制、哨兵与集群详解-优快云博客

宏观角度回顾一下Redis实现高可用相关的技术。它们包括：持久化、复制、哨兵和集群

持久化：持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
复制：复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。
集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

持久化

RDB方式

对性能的影响相对较小
将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。所以会存在很多个文件

save //阻塞保存
bgsave //后台不阻塞保存
save m n //当m秒内发生n次变化时，会触发bgsave
主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令
执行shutdown命令时，自动执行rdb持久化

AOF方式

实时；文件大、恢复速度慢、对性能影响大
将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置：appendonly yes
因此AOF不需要触发，记录Redis的每条写命令

主从

单机版的Redis属于保证CP(Consistency & Partition-Tolerancy)而牺牲A(Availability)
主从模式是AP

主节点和多个从节点。提供了冗余和故障转移能力，适合一些读多写少的应用场景（主写从读）。

主从复制的开启，完全是在从节点发起的；不需要我们在主节点做任何事情。

从节点开启主从复制，有3种方式：

配置文件
在从服务器的配置文件中加入：slaveof <masterip> <masterport>
启动命令
redis-server启动命令后加入 --slaveof <masterip> <masterport>
客户端命令
Redis服务器启动后，直接通过客户端执行命令：slaveof <masterip> <masterport>，则该Redis实例成为从节点。

通过slaveof no one断开。需要注意的是，从节点断开复制后，不会删除已有的数据，只是不再接受主节点新的数据变化。

全部复制

场景
用于初次复制或其他无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作。
同步流程
1. 主节点 bgsave生成当前RDB文件 + 复制缓冲区记录后续命令
2. RDB文件发给从节点 >> 从节点清空老数据、载入新RDB文件
3. 复制缓冲区命令发给从节点 >> 从节点执行这些写命令

部分复制

Redis2.8开始提供部分复制，
从节点发送psync命令请求同步数据，此时根据主从节点当前状态的不同，选择同步方式是全量复制或部分复制

重要概念
1. 复制偏移量（offset）
  主节点和从节点分别维护一个：记录节点传递/接收的字节数
  判断主从节点的数据库状态是否一致，差多少数据没同步
2. 复制积压缓冲区
  先进先出(FIFO)队列默认大小1MB （建议根据平均中断时间*每秒产生命令进行调整）
  记录主节点最新执行命令，超过队列大小的会被挤出缓冲区
3. 服务器运行ID(runid) ：
  识别每个节点的随机ID(每次启动都不一样)
  从节点会将主节点的runid存起来，断开重连的时候判断是否同步过
场景
用于网络中断等情况后的复制，只将中断期间主节点执行的写命令发送给从节点，与全量复制相比更加高效。
使用条件
主节点的runid没变，且 offset之后的数据在复制积压缓冲区中

哨兵

Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移

在这里插入图片描述

哨兵节点：
哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
数据节点：
主节点和从节点都是数据节点。

哨兵系统部署

哨兵系统中节点分为数据节点与哨兵节点

启动数据节点

哨兵系统中的主从节点，与普通的主从节点配置是一样的

启动哨兵节点

部署建议
哨兵节点的数量应不止一个，一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。
哨兵节点的数量是奇数
哨兵节点的配置应一致，包括硬件、参数、时间

配置sentinel.conf

//至少需要 N个哨兵节点同意，才能判定主节点故障并进行故障转移。
sentinel monitor 主节点名称 主节点ip 主节点端口 N
//一个哨兵可以监控多个主节点，通过配置多条sentinel monitor即可实现
sentinel monitor ...
sentinel monitor ...

启动 redis-sentinel

# 启动有两种方式，二者作用是完全相同的
redis-sentinel sentinel.conf

redis-server sentinel.conf --sentinel

故障转移
在故障转移阶段，哨兵和主从节点的配置文件都会被改写。

对于主从节点，主要是slaveof配置的变化：新的主节点没有了slaveof配置，其从节点则slaveof新的主节点。
对于哨兵节点，除了主从节点信息的变化，纪元(epoch)也会变化，下图中可以看到纪元相关的参数都+1了。

哨兵的原理

定时任务：
每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：
通过向主从节点发送info命令 获取最新的主从结构；
通过发布订阅功能 获取其他哨兵节点的信息；
通过向其他节点发送ping命令进行 心跳检测，判断是否下线。
主观下线：
在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。
客观下线（主节点）：
哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对主节点进行客观下线。
只实现了主节点的故障转移；从节点故障时只会被下线，不会进行故障转移
选举领导者哨兵节点
主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。
故障转移
1. 在从节点中选择新的主节点：
  slave-priority优先级 > 复制偏移量最大 > runid最小
2. 更新主从状态：
  通过slaveof no one命令，让选出来的从节点成为主节点；
  通过slaveof命令让其他节点成为其从节点
3. 将已经下线的主节点设置为新的主节点的从节点
  当重新上线后，它会成为新的主节点的从节点

集群

Redis 3.0开始引入的。提供高可用性、高性能和可扩展性。

通过分片( sharding ) 将数据均匀地分布在多个节点上，
允许在增加或减少节点时进行水平扩展
并提供复制和故障转移。

redis-cluster

redis-cluster 启动节点
节点握手，形成集群网络
集群数据分区分配哈希槽【hash slot】
【可选】指定主节点副本 cluster replicate

集群节点
在集群中，没有数据节点与非数据节点之分：所有的节点都存储数据，也都参与集群状态的维护。
不过节点会开2个端口。
1. 普通端口
  用于为客户端提供服务，节点数据迁移
2. 集群端口
  节点之间的通信：增减节点、故障转移等操作

数据分区

将数据自动切分（split）到多个节点的能力。

哈希槽【hash slot】=虚拟节点

概念
虚拟节点，数据hash不直接放在实际节点，
变成：数据hash >> 槽 >> 实际节点
hash作用：
扩展写数据能力，让多个节点能承担写数据
槽作用：
解耦了数据和实际节点之间的关系，增加或删除节点对系统的影响变小
1. 一致性hash：一个实际节点下线，相邻节点要独自承载它的全部数据
2. 哈希槽：一个实际节点下线，把它的槽均匀分配给其他节点