Redis分布式缓存-数据持久化

1.单节点Redis存在的问题

• 数据丢失问题
  问题：Redis是内存存储，服务重启可能会丢失数据
  解决方式：实现Redis数据持久化
• 并发能力问题
  问题：单节点Redis并发能力虽然不错，但也无法满足如618这样的高并发场景
  解决方式：搭建主从集群，实现读写分离
• 故障恢复的问题
  问题：如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段
  解决方式：利用Redis哨兵，实现健康检测和自动恢复
• 存储能力问题
  问题：Redis基于内存，单节点能存储的数据量难以满足海量数据的需求
  解决方式：搭建分片集群，利用插槽机制实现动态扩容

2.Redis持久化

2.1 RDB持久化

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

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

RDB的其它配置也可以在redis.conf文件中设置：

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。
fork采用的是copy-on-write技术：

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作。
  
  总结：
  1.RDB方式bgsave的基本流程？
• fork主进程得到一个子进程，共享内存空间
• 子进程读取内存数据并写入新的RDB文件
• 用新RDB文件替换旧的RDB文件。
  2.RDB会在什么时候执行？save 60 1000代表什么含义？
• 默认是服务停止时。
• 代表60秒内至少执行1000次修改则触发RDB
  3.RDB的缺点？
• RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
• fork子进程、压缩、写出RDB文件都比较耗时

2.2 AOF持久化

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

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

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


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

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

3.RDB与AOF对比

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