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 编写配置参数
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对象
/**
* 实现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 表示可以监听任何网络地址的信息
标签：缓存,slave,Redis,master,RDB,服务器,节点,分布式 From： https://blog.csdn.net/qq_52174380/article/details/143996596