Redis高级篇 —— 分布式缓存

小小低头哥

于 2024-10-10 23:34:28 发布

阅读量1k

点赞数 19

分类专栏： Redis面试文章标签：缓存 redis 分布式 java

本文链接：https://blog.csdn.net/weixin_49429082/article/details/142834529

版权

Redis面试专栏收录该内容

5 篇文章 0 订阅

订阅专栏

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节点一起丢失。这样数据跟着插槽走，永远都能找到对应的位置。

在这里插入图片描述