Redis·进阶(二)·分布式缓存

1 单机的Redis存在四大问题

1.1 数据丢失问题

解决方案	实现Redis数据持久化

持久化：由于Redis缓存存储在内存中，而内存不存储数据（内存读写快），磁盘存储数据（IO交互多，读写慢），我们需要将Redis存储在内存中数据持久化存储到磁盘中。

1.2 故障恢复问题

解决方案	利用Redis哨兵，实现健康检测和自动恢复

1.3 并发能力问题

解决方案	搭建主从集群，实现读写分离

1.4 存储能力问题

解决方案	搭建分片集群。利用插槽机制实现动态扩容

2 数据丢失问题：Redis持久化解决RDB与AOF

2.1 RDB持久化

RDB（Redis Database Backup file）（Redis数据备份文件）：也称Redis数据快照。把内存中的数据记录到磁盘中。
当Redis实例故障重启，从磁盘读取快照文件（RDB文件），恢复数据。默认保存在当前运行目录。

2.1.1 执行时机

执行时机	解释	测试
执行save命令	save命令会使主进程执行RDB，过程中其它命令都会被阻塞。只有在数据迁移时可能用到此命令
执行bgsave命令	此命令可以异步执行RDB ,执行后开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。
停机时	Redis停机时执行一次save命令，实现RDB持久化。
触发RDB条件	Redis内部有触发RDB机制，在redis.conf文件中修改

2.1.2 触发RDB条件及其他配置

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000 

RDB的其它配置也可以在redis.conf文件中设置，格式如下：

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./ 

2.1.3 RDB原理

RDB原理：首先，bgsave开始时fork主进程得到子进程，子进程共享主进程的存数据。其次，完成fork后读取内存数据并写入 RDB 文件。

fork采用copy-on-write技术：

• 主进程执行读操作时，访问共享内存；
• 主进程执行写操作时，拷贝一份数据，执行写操作。

2.1.4 RDB方式bgsave的基本流程

首先，fork主进程得到一进程，共享内存空间，其次，子进程读取内存数据并写入新的RDB文件，最后，用新RDB文件替换旧的RDB文件。

2.1.5 RDB的缺点

• RDB执行间隔时间长（因为其要保存一时刻redis缓存的所有快照），两次RDB之间写入数据有丢失风险
• fork子进程、压缩、写出RDB文件都比较耗时

2.2 AOF持久化

2.2.1 AOF原理

AOF(Append Only File)（追加文件）：Redis处理的每个写命令都要记录在AOF文件（命令日志文件）。

2.2.2 AOF配置

2.2.2.1 AOF默认关闭，修改redis.conf配置文件开启AOF

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

2.2.3 AOF命令记录频率三种策略

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

2.2.4 AOF文件重写

2.2.4.1 为什么进行重写：

因为AOF方式是记录命令的，因此会比RDB方式产生的文件大的多。**

2.2.4.2 重写的思路：

例如，对同一key的多此操作，只有最后一次才有意义，我们要做的就是减少此类操作中产生的垃圾命令。

2.2.4.3 实现：

执行bgrewriteaof命令，让AOF文件执行重写功能，用最少命令达到相同效果。

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

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb 

2.3 RDB与AOF对比

3 并发能力问题：Redis主从

3.1 为什么要搭建Redis主从架构

单节点Redis并发能力有上限，如需提高并发能力，需搭建主从集群，实现读写分离。

3.1 搭建主从架构

3.2 主从数据同步原理

3.2.1 全量同步

主从数据同步原理：首先，主从第一次建立连接时，执行全量同步（将RDB文件通过网络传输给slave）

3.2.2 问题：master如何得知salve是第一次来连接呢？以及master如何判定此salve是自己的从节点？

答：salve做数据同步，首先，salve向master发送自己原有的replid和offset，当master发现slave发送来的replid与自己不一致，说明这是全新slave需要做全量同步，然后，master会将自己的replid和offset发送给slave，slave保存这些信息。以后slave的replid就与master一致,也判定此salve是自己的从节点。

即：master判断某节点是否为第一次同步的:依据是比较replid是否相同。

名词	解释
Replication Id (replid)（数据集标记）	id一致说明是同一数据集。每一个master都有唯一replid，slave会继承master节点replid
offset (偏移量)	随repl_baklog中数据增多而增大。slave完成同步时记录当前同步的offset。如slave的offset小于master的offset，说明slave数据落后于master，需要更新。

3.2.3 增量同步

4 故障恢复问题：Redis哨兵

5 存储能力问题：Redis分片集群

master主节点复制为什么要用RDB为什么不用AOF？

答：理解错误，先是RDB，后是AOF，也就是说是RDB跟AOF结合使用