3.1 Redis持久化

一、Redis单节点的问题

1. 数据丢失问题

2. 并发能力问题

3. 存储能力问题

4. 故障恢复问题

二、解决方案

1. 数据丢失问题——实现Redis数据持久化

2. 并发能力问题——搭建筑从集群，实现读写分离

3. 存储能力问题——搭建分片集群，利用插槽机制实现动态扩容

4. 故障恢复问题——利用Redis哨兵，实现健康检查和自动回复

三、Redis持久化——RDB

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

2. 快找文件称为RDB文件，默认是保存在当前运行目录

   1. redis-cli命令中执行：

      1. save——主进程保存，会阻塞进程，直到保存结束

      2. bgsave——开启子进程保存，避免主进程受影响

   2. Redis停机时会执行一次RDB

3. 安装Redis可以参考附录

4. 运行，需要指定配置文件redis-server redis.conf

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

   save 900 1
   save 300 10
   save 60 10000

   解释：900秒内，如果至少有1个key被修改，则执行bgsave(异步持久化)

   ​ 300秒内，如果至少有10个key被修改，则执行bgsave(异步持久化)

   ​ 60秒内，如果至少有10000个key被修改，则执行bgsave(异步持久化)

   如果是save ""则表示禁用RDB

6. RDB的其他配置

   # 是否压缩，建议不开启，压缩会消耗cpu，磁盘比较便宜
   rdbcompression yes
   # RDB文件名称
   dbfilename dump.rdb
   # 文件保存的路径目录
   dir ./

7. RDB执行原理

   1. bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件

   2. fork采用的是copy-on-write技术：

      1. 当主进程执行读写操作时，访问共享内存

      2. 当主进程执行接操作时，则会拷贝一份数据，执行写操作

四、Redis持久化——AOF

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

2. AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF

   # 是否开启AOF功能，默认no
   appendonly yes
   # appendfilename "appendonly.aof"

3. AOF的命令记录的频率也可以通过redis.conf文件来配

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

   配置项	刷盘机制	优点	缺点
   aleays	同步刷盘	可靠性高，几乎不丢数据	性能影响大
   everysec	每秒刷盘	性能适中	最多丢失一秒数据
   no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

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

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

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

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

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

   备注：Redis后续有计划将两者合二为一