分布式缓存-Redis集群

单点Redis的问题

数据丢失问题

Redis是内存存储，服务重启可能会丢失数据

并发能力问题

单节点Redis并发能力虽然不错，但也无法满足如618这样的高并发场景

故障恢复问题

如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段

存储能力问题

Redis基于内存，单节点能存储的数据量难以满足海量数据需求

一、Redis持久化

1、RDB持久化

RDB

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称为RDB文件，默认是保存在当前运行目录。

Redis停机时会执行一次RDB。

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

RDB的其它配置也可以在redis.conf文件中设置：

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术：

• 当主进程执行读操作时，访问共享内存；

• 当主进程执行写操作时，则会拷贝一份数据，执行写操作。

总结：

RDB方式bgsave的基本流程？

• fork 主进程得到一个子进程，共享内存空间

• 子进程读取内存数据并写入新的 RDB 文件

• 用新 RDB 文件替换旧的 RDB 文件。

RDB会在什么时候执行？save 60 1000代表什么含义？

• 默认是服务停止时。

• 代表 60 秒内至少执行 1000 次修改则触发 RDB

RDB的缺点？

• RDB 执行间隔时间长，两次 RDB 之间写入数据有丢失的风险

• fork 子进程、压缩、写出 RDB 文件都比较耗时

2、AOF持久化

AOF

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

AOF的命令记录的频率也可以通过redis.conf文件来配：

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源 但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见

二、Redis主从

1、搭建主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

总结：

假设有A、B两个Redis实例，如何让B作为A的slave节点？

• 在 B 节点执行命令： slaveof A 的 IP A 的 port

2、主从数据同步原理

主从第一次同步是全量同步：

master如何判断slave是不是第一次来同步数据？这里会用到两个很重要的概念：

• Replication Id ：简称 replid ，是数据集的标记， id 一致则说明是同一数据集。每一个 master 都有唯一的 replid ， slave 则会继承 master 节点的 replid

• offset ：偏移量，随着记录在 repl_baklog 中的数据增多而逐渐增大。 slave 完成同步时也会记录当前同步的 offset 。如果 slave 的 offset 小于 master 的 offset ，说明 slave 数据落后于 master ，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据

总结：

简述全量同步的流程？

• slave 节点请求增量同步

• master 节点判断 replid ，发现不一致，拒绝增量同步

• master 将完整内存数据生成 RDB ，发送 RDB 到 slave

• slave 清空本地数据，加载 master 的 RDB

• master 将 RDB 期间的命令记录在 repl_baklog ，并持续将 log 中的命令发送给 slave

• slave 执行接收到的命令，保持与 master 之间的同步

三、Redis哨兵

1、哨兵的作用和原理

哨兵的作用

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下：

• 监控 ： Sentinel 会不断检查您的 master 和 slave 是否按预期工作

• 自动故障恢复 ：如果 master 故障， Sentinel 会将一个 slave 提升为 master 。当故障实例恢复后也以新的 master 为主

• 通知 ： Sentinel 充当 Redis 客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给 Redis 的客户端

服务状态监控

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

• 主观下线：如果某 sentinel 节点发现某实例未在规定时间响应，则认为该实例 主观下线 。

• 客观下线：若超过指定数量（ quorum ）的 sentinel 都认为该实例主观下线，则该实例 客观下线 。 quorum 值最好超过 Sentinel 实例数量的一半。

选举新的master

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

• 首先会判断 slave 节点与 master 节点断开时间长短，如果超过指定值（ down-after-milliseconds * 10 ）则会排除该 slave 节点

• 然后判断 slave 节点的 slave-priority 值，越小优先级越高，如果是 0 则永不参与选举

• 如果 slave-prority 一样，则判断 slave 节点的 offset 值，越大说明数据越新，优先级越高

• 最后是判断 slave 节点的运行 id 大小，越小优先级越高。

如何实现故障转移

当选中了其中一个slave为新的master后（例如slave1），故障的转移的步骤如下：

• sentinel 给备选的 slave1 节点发送 slaveof no one 命令，让该节点成为 master

• sentinel 给所有其它 slave 发送 slaveof 192.168.150.101 7002 命令，让这些 slave 成为新 master 的从节点，开始从新的 master 上同步数据。

• 最后， sentinel 将故障节点标记为 slave ，当故障节点恢复后会自动成为新的 master 的 slave 节点

总结：

Sentinel的三个作用是什么？

• 监控

• 故障转移

• 通知

Sentinel如何判断一个redis实例是否健康？

• 每隔 1 秒发送一次 ping 命令，如果超过一定时间没有相向则认为是主观下线

• 如果大多数 sentinel 都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

• 首先选定一个 slave 作为新的 master ，执行 slaveof no one

• 然后让所有节点都执行 slaveof 新 master

• 修改故障节点配置，添加 slaveof 新 master

2、搭建哨兵集群

3、RedisTemplate的哨兵模式

在Sentinel集群监管下的Redis主从集群，其节点会因为自动故障转移而发生变化，Redis的客户端必须感知这种变化，及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换。

首先，我们引入的Demo工程：

1.在pom文件中引入redis的starter依赖：

2.然后在配置文件application.yml中指定sentinel相关信息：

3.配置主从读写分离

这里的ReadFrom是配置Redis的读取策略，是一个枚举，包括下面选择：

• MASTER ：从主节点读取

• MASTER_PREFERRED ：优先从 master 节点读取， master 不可用才读取 replica

• REPLICA ：从 slave （ replica ）节点读取

• REPLICA _PREFERRED ：优先从 slave （ replica ）节点读取，所有的 slave 都不可用才读取 master

四、Redis分片集群

1、搭建分片集群

分片集群结构

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

• 海量数据存储问题

• 高并发写的问题

使用分片集群可以解决上述问题，分片集群特征：

• 集群中有多个 master ，每个 master 保存不同数据

• 每个 master 都可以有多个 slave 节点

• master 之间通过 ping 监测彼此健康状态

• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

2、散列插槽

Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到：

数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：

• key 中包含 "{}" ，且“ {} ”中至少包含 1 个字符，“ {} ”中的部分是有效部分

• key 中不包含“ {} ”，整个 key 都是有效部分

例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。

总结：

Redis如何判断某个key应该在哪个实例？

• 将 16384 个插槽分配到不同的实例

• 根据 key 的有效部分计算哈希值，对 16384 取余

• 余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

• 这一类数据使用相同的有效部分，例如 key 都以 {typeId} 为前缀

3、集群伸缩

添加一个节点到集群

redis-cli --cluster提供了很多操作集群的命令，可以通过下面方式查看：

比如，添加节点的命令：

4、故障转移

当集群中有一个master宕机会发生什么呢？

1.首先是该实例与其它实例失去连接

2.然后是疑似宕机：

3.最后是确定下线，自动提升一个slave为新的master：

数据迁移

利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。其流程如下：

手动的Failover支持三种不同模式：

• 缺省：默认的流程，如图 1~6 歩

• force ：省略了对 offset 的一致性校验

• takeover ：直接执行第 5 歩，忽略数据一致性、忽略 master 状态和其它 master 的意见

5、RedisTemplate访问分片集群

RedisTemplate底层同样基于lettuce实现了分片集群的支持，而使用的步骤与哨兵模式基本一致：

1. 引入 redis 的 starter 依赖

2. 配置分片集群地址

3. 配置读写分离

与哨兵模式相比，其中只有分片集群的配置方式略有差异，如下：