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各有自己的优缺点，如果对数据安全性要求较高，在实际开辟中往往会联合两者来利用。
RDBAOF持久化方式定时对整个内存做快照记载每一次执行的命令数据完备性不完备，两次备份之间会丢失相对完备，取决于刷盘计谋文件巨细会有压缩，文件体积小记载命令，文件体积很大宕机规复速率很快慢数据规复优先级低，因为数据完备性不如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
- /**
- * 实现redis集群的读写分离
- *
- * @return
- */
- @Bean
- public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer() {
- return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
- }
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 体现可以监听任何网络地址的信息
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
