Redis高级篇 —— 分布式缓存

Redis高级篇 —— 分布式缓存

1 Redis持久化

1.1 RDB

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

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

• Redis是单线程的 一旦主线程执行RDB就会阻塞所有Redis的命令。 而这个RDB是把数据写到磁盘，写磁盘是比较慢的 当数据量比较大的时候，写的时间就很长。

  因此这个命令不推荐使用，一般在Redis要停机前再使用。所以在Redis运行过程中 推荐使用bgsave，后台异步执行 ，是由一个额外的子进程来执行的。

​ Redis停机会执行一次RDB。

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

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

​ 因此不用但是Redis用着用着突然停机，导致数据没来得及保存。Redis自动会保存数据。

1.2 RDB的fork原理

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

物理内存 可以理解为就是计算机中的内存条。Linux中进程不能直接操作物理内存，但是每个进程都会被分配一个虚拟内存，主进程只能操作虚拟内存，而后操作系统会维护一个虚拟内存与物理内存之间的映射关系表，这个表就称为 页表 。

所以主进程操作虚拟内存，而虚拟内存基于页表的映射关系 到物理内存真正的存储位置。这样就能实现对物理内存的读写。

而执行frok操作时，会启动一个子进程。fork过程不是把内存数据做拷贝，仅仅是把页表做拷贝，也就是把映射关系拷贝给子进程。而子进程和主进程有了相同的映射关系，当子进程在操作自己的虚拟内存时，因为映射关系和主进程一样，所以能映射到和主进程一样的物理内存区域。就实现了子进程与主进程物理内存的共享。这样就无需拷贝内存中的数据，直接享受内存共享，这个速度就会变得非常快。这样主进程frok的时间就会尽可能短，阻塞的时间也会短。

而后子进程就可以放心的读取自己内存的数据，再写入到RDB文件中。

但是还有一个问题，就是子进程在读的过程中，此时主进程再写怎么办？先再了解一下fork

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

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作，则会拷贝一份数据，执行写操作。

也就是说当子进程在读的时候，如果主进程此时要写，那么就会拷贝一份相同的数据，比如数据B（fork时 会将物理内存中的Redis数据设置为只读模式），然后对拷贝的数据副本进行读写，页表的映射关系也会改变成新的数据副本。

这样其实还有一个问题，就是如果子进程写的速度太慢了，此时写的操作又各种各样，极端情况下，导致每个数据都拷贝了一个副本，那么此时Redis内存就翻倍了，本来16GB的，现在32GB了。 所以Redis一般是要预留一些内存空间的，一台服务器32G，则肯定不能都给Redis存储数据，这样容易导致做RDB时，内存溢出。

1.3 RDB总结

写入数据时间久，万一两次持久化的间隔短，导致还没写完又开始新写了，就导致数据丢失。

1.4 AOF持久化

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

比如设置了123，首先会把对应数据保存在key value中，而后再把命令写入到AOF文件中。

当Redis出现故障，相要恢复数据，只需要读取AOF文件，把里面的命令从头到尾执行一遍，数据就恢复了。

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

AOF的命令记录的频率也可以通过redis.conf文件来匹配。有三种方案，下面三种：

第一种方案是写key value和写入AOF文件一起执行完才算redis命令执行完，绝对安全，但是性能是最差的。

第二种方案性能比第一种方案好，但是最多会丢失1s内的数据，牺牲了一定的可靠性。

第三种方案性能最好，但是安全性最差。

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

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

命令远远要大于数据，再加上RDB会有压缩，所以AOF文件体积要比RDB文件大

AOF也是异步的

1.5 RDB和AOF的对比

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

RDB文件小，宕机后恢复速度快，AOF反之。 RDB持久化一次间隔时间太长，数据容易丢失

2 Redis主从

2.1 搭建主从架构

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

开启主从关系后，就决定了主节点只能写，从节点只能读的关系。

2.2 数据同步原理

2.2.1 全量同步

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

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

• replication Id ：简称replid，是数据集的标记，id一致则说明是同一数据集。每个master都有唯一的replid，slave则会继承master节点的replid。
• offset ： 偏移量，随着记录在repl_backlog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

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

那么问题来了：master如何判断slave节点是不是第一次来做数据同步？

只要判断id相不相同就行了，相同就不是第一次来，不同就是第一次来。

2.2.2 增量同步

主从第一次同步是 全量同步 ，但如果slave重启后同步，则执行 增量同步

注意： repl_baklog大小有上限。写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，只能再次全量同步。

可以从以下几个方面来优化Redis主从集群：

• 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO
• Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
• 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
• 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主—从-从链式结构，减少master压力

3 Redis哨兵

前面介绍了slave节点宕机恢复后可以找master节点同步数据，那么master节点宕机怎么办？

如果做了Redis数据持久化，那么重启一下是没问题，可以恢复数据的，继续当master。但是需要考虑的一点是，在master Redis宕机的这一段时间内，再重启数据恢复的过程当中，用户是无法进行写操作的，因为master挂了，那么可用性就下降了。

解决方法： 可以一直监控Redis集群状态，一旦发现master宕机，就立即让其中一个slave变成新的master，因为slave一直在数据同步，所以slave有master所有数据，这样就可以无缝衔接，就保证Redis集群一直健康的。对外来说什么故障都没发生过。等到原来的master恢复了，就让其当slave就可以了。

这个检测和重启的动作就由哨兵来做。

3.1 哨兵的作用和原理

3.1.1 哨兵的作用

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

• 监控：Sentinel会不断检查你的master和slave是否按期工作
• 自动故障恢复： 如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主。
• 通知： Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端。
  • 就是其实Redis客户端也是通过Sentinel来知道集群中master的地址的，一旦发生变更，Sentinel会选一个新的master并把地址给Redis客服端。
    

3.1.2 服务状态监控

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

• 主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例 主观下线。
• 客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例 客观下线 。quorum值最好超过Sentinel实例数量的一半。
  

3.1.3 选举新的master

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

• 首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10） 则会排除该slave节点
• 然后判断slave节点的salve-priority值（可以在配置文件中配置），越小优先级越高，如果是0则永不参与选举
• 如果slave-priority一样，则判断slave节点的offset值 ，越大说明数据越新，优先级越高。
• 最后判断slave节点的运行id和大小，越小优先级越高。（其实完成以上几步，剩下的slave都可以作为新的master节点，最后这步就是定义一个选的唯一性规则，实际都可以选了。）

3.1.4 如何实现故障转移

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

• sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为新的master，该节点配置文件中就修改为了主节点

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

• 最后，sentinel将故障节点标记为slave（在该节点对应的配置文件中，将此节点修改为slave，并告知其信master节点），当故障节点恢复后会自动成为新的master的slave节点。

3.1.5 redis集群（哨兵模式）脑裂

由于网络原因，主节点和哨兵处于不同的网络分区，那么哨兵只能去监测从节点，它监测不到主节点了。那么哨兵就会按照选举规则从从节点中选出一个新的主节点，但是值得注意的是老的主节点还没有挂，那么此时就有两个主节点了，就像大脑分裂了一样。

现在就有问题了，因为目前的客户端还连接的是老的master，他会持续往老的主节点写入数据，新的节点就不能同步数据，因为网络还有问题。

假如现在网络正常了，哨兵会将老的master强制降为slave，并且这个salve还会从新的master中同步数据（我们知道第一次同步数据是会先清空自己的数据的），然后客户端从Sentinel中接收新的master节点地址并进行连接。这就尴尬了，这个slave中原本作为master保存的数据都没了。脑裂问题就导致数据丢失了

redis中有两个配置参数：
min-replicas-to-write 1 表示最少的salve节点为1个

• 就是说当主节点至少有一个从节点时，才允许接收客户端的数据，否则直接拒绝请求

min-replicas-max-lag 5 表示数据复制和同步的延迟不能超过5秒

通过这两个配置，如果发生脑裂了，达不到这两个要求，就拒绝客户端的请求，这样就能避免大量的数据丢失了。

3.1.6 总结

3.2 RedisTemplate的哨兵模式

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

4 Redis分片集群

4.1 分片集群结构

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

• 海量数据存储问题
• 高并发写的问题

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

• 集群中有多个master，每个master保存不同数据
• 每个master都可以有多个slave节点
• master之间通过ping监控彼此健康状态，这样连额外的哨兵也不用了，
• 客户端请求可以访问集群任意节点，最红都会被转发到正确节点。

多个master可以储存海量数据，并且高并发的读。每个master都有集群，有对应的slave，就可以高并发的读。

4.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值。而每个节点包含不同的slot值，一旦key映射到了对应的slot值，它就知道自己对应的是哪个master节点上的key了。

之所以与插槽绑定不是直接与master节点绑定，是因为万一master节点宕机或者集群扩容、伸缩，可以将此节点对应的插槽直接绑定到另一个活着的节点上，不至于跟着master节点一起丢失。这样数据跟着插槽走，永远都能找到对应的位置。

最后这个放在同一个实例中很妙，相同类型数据的key加个大括号，大括号里数据都一样，作为key的前缀。然后相同类型不同数据的后缀不一样，这样就能都在一个slot插槽里，且key不完全相同。

4.3 故障转移

分片集群虽然没有哨兵，但是也有故障转移的功能。

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

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

• 然后是疑似宕机：

  

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

  

上面那种是自动的故障转移，是有的节点意外宕机了，自动选一个新的节点。

有的时候需要手动转移，比如换一个更好的节点替代这个节点。

手动转移：

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

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

• 缺省：默认的流程，如上图
• force：省略了对offset的一致性校验
• takeover：直接执行第5步，忽略数据一致性、忽略master状态和其它master的意见

4.4 RedisTemplate访问分片集群

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

• 引入redis的starter依赖

• 配置分片集群地址

• 配置读写分离