十一、Redis——分布式缓存

目录

1.1  单点Redis存在的问题

1.2 Redis持久化

1.2.1 RDB持久化方式

1.2.2 AOF持久化方式

1.3 RDB和AOF持久化方式对比分析

1.4 Redis主从集群

1.4.1 搭建Redis主从架构

         1.4.2 数据同步原理

1.5 Redis的哨兵 

1.5.1 Redis哨兵的作用和原理

1.6 Redis分片集群

1.6.1 分片集群结构

1.6.2 散列插槽

1.6.3 数据迁移 

1.1  单点Redis存在的问题

1.2 Redis持久化

1.2.1 RDB持久化方式

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

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

Redis停机时会执行一次RDB。

小总结：

RDB方式bgsave的基本流程？

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

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

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

RDB会在什么时候执行？save 60 1000代表什么含义？

• 默认是服务停止时。

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

RDB的缺点？

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

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

1.2.2 AOF持久化方式

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

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

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

1.3 RDB和AOF持久化方式对比分析

1.4 Redis主从集群

1.4.1 搭建Redis主从架构

小总结：

假设有A、B两个Redis实例，如何让B作为A的slave节点？

• 在 B 节点执行命令： slaveof A 的 IP A 的 port。

1.4.2 数据同步原理

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

• Replication Id ：简称 replid ，是数据集的标记， id 一致则说明是同一数据集。每一个 master 都有唯一的 replid ， slave 则会继承 master 节点的 replid

• offset ：偏移量，随着记录在 repl_baklog 中的数据增多而逐渐增大。 slave 完成同步时也会记录当前同步的 offset 。如果 slave 的 offset 小于 master 的 offset ，说明 slave 数据落后于 master ，需要更新。

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

  小总结：

简述全量同步的流程？

• slave 节点请求增量同步；

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

• master 将完整内存数据生成 RDB ，发送 RDB 到 slave；

• slave 清空本地数据，加载 master 的 RDB；

• master 将 RDB 期间的命令记录在 repl_baklog ，并持续将 log 中的命令发送给 slave；

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

  

总结：

简述全量同步和增量同步区别？

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

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

什么时候执行全量同步？

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

• slave 节点断开时间太久， repl_baklog 中的 offset 已经被覆盖时。

什么时候执行增量同步？

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

1.5 Redis的哨兵 

1.5.1 Redis哨兵的作用和原理

 1.5.1.1 服务状态监控

1.5.1.2 选举新的Master

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

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

• 然后判断 slave 节点的 slave-priority 值，越小优先级越高，如果是 0 则永不参与选举

• 如果 slave- prority 一样，则判断 slave 节点的 offset 值，越大说明数据越新，优先级越高

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

 1.5.1.3 如何实现故障转移

总结：

Sentinel的三个作用是什么？

• 监控

• 故障转移

• 通知

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

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

• 如果大多数 sentinel 都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

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

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

• 修改故障节点，执行 slaveof 新 master

1.6 Redis分片集群

1.6.1 分片集群结构

1.6.2 散列插槽

小总结：

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

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

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

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

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

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

1.6.3 数据迁移 

参考文献：

黑马程序员Redis入门到实战教程，深度透析redis底层原理+redis分布式锁+企业解决方案+黑马点评实战项目_哔哩哔哩_bilibili