第三章分布式缓存Redis

1. Redis持久化

1.1 RDB持久化

Redis Database Backend备份机制，也叫Redis快照。在Redis中，fork用于创建子进程来进行数据持久化操作，这样可以避免阻塞主进程，从而提高性能。

1.1.1 RDB方式bgsave的基本流程？

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

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

3.用新的RDB文件替换旧的RDB文件

1.1.2 RDB会在什么时候执行？

默认是服务停止时执行。

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

1.1.3 RDB的缺点？

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

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

1.2 AOF持久化

Append only file,将Redis的写命令持久化到文件中。

当某个命令执行多次时，只有最后一个命令是有效命令，为了避免AOF的文件过大，可以使用bgrewriteaof命令实现对命令的重新写入。

1.3 RDB和AOF比较

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

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

2. Redis主从

2.1 全量同步的流程？

1.slave节点请求增量同步

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

3.master将完整内存数据生成RDB，发送给slave

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

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

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

2.2 增量同步

slave根据offset偏移量去master的repl_backlog中同步数据。但是当文件(循环列表)中的数据太多被重新覆盖后，就无法进行增量同步，只能全量同步。

2.3 Redis集群优化

1.在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO

2.Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO

3.适当提高reply_backlog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步

4.限制一个master上的slave节点数量，如果有太多slave，则可以采用主-从-从链式结构，减少master压力

2.4 全量同步和增量同步的区别

全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_backlog,逐个发送给slave。

增量同步：slave提交自己的offset到master，master获取repl_backlog中从offset之后的命令给slave。

2.5 什么时候执行全量同步？

slave节点第一次连接master节点时

slave节点断开时间太久，repl_backlog中的offset已经覆盖时

2.6 什么时候执行增量同步？

slave节点断开又恢复，并且在repl_backlog中能找到offset时

2.7 简要说明repl_backlog的原理及作用是什么？

当一个从服务器连接到主服务器时，主服务器会开始将repl_backlog中的数据发送给从服务器，以便从服务器可以更新其数据以匹配主服务器的状态。
如果一个从服务器断开并重新连接，主服务器可以使用repl_backlog中的数据来帮助从服务器捕获到断开期间的所有更改，slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。
repl_backlog的大小是可配置的，如果它被设置得太小，那么在从服务器断开并重新连接后，可能无法获取到所有的更改。如果设置得太大，那么会消耗更多的内存。
repl_backlog是一个环形缓冲区，当它满了之后，新的数据会覆盖旧的数据。此时如果slave需要同步，却发现自己的offset都没有了，无法完成增量同步了。就只能做全量同步。
因此，repl_backlog在Redis的主从复制中起着非常重要的作用，它可以帮助从服务器在断开后快速地捕获到所有的更改。

3. Redis哨兵

3.1 Sentinel的三个作用是什么？

监控（Monitoring）：哨兵会不断地检查你的Redis主服务器和从服务器是否正常工作。
通知（Notification）：如果某个Redis实例出现故障，哨兵可以通过API向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）：如果一个主服务器无法正常工作，哨兵可以开始故障迁移过程，将一个从服务器升级为主服务器，然后由其他从服务器开始复制新的主服务器。
配置提供者（Configuration provider）：客户端可以询问哨兵来发现主服务器和从服务器的地址。
通过以上功能，Redis哨兵提供了一种自动处理Redis节点故障的机制，增强了系统的可用性和稳定性。

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

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

如果大多数Sentinel都认为实例下线，则判定服务下线

3.3 故障转移步骤有哪些？

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

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

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

3.4 如果redis主节点宕机了，哨兵是如何选取主节点的？

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

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

2.然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举。如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高。

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

3.5 配置读写分离

3.5.1 编写配置参数

yaml 复制代码

spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.137.110:27001
        - 192.168.137.110:27002
        - 192.168.137.110:27003

3.5.2 添加Bean对象

java 复制代码

    /**
     * 实现redis集群的读写分离
     *
     * @return
     */
    @Bean
    public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer() {
        return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
    }

4. 分片集群

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

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

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

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

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

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

5. 踩坑记录

1.Redis的主从集群搭建失败

一直报错。

经老师指点，发现redis的配置文件需要修改一个参数：

bind 0.0.0.0

默认是bind 127.0.0.1 ，表示redis监听本地地址；

bind 0.0.0.0 表示可以监听任何网络地址的信息

第三章 分布式缓存Redis