![]()
0.基本概念
-
AOF
-
持久化到磁盘
-
先操作后记录日志
-
持久化有三种可选项
- 每次
- 每秒
- 跟随操作系统
-
恢复数据时需要将日志回放（相对较慢）
-
优化，AOF重写，缩小日志量
-
-
RDB\
- 内存数据在某一刻的状态记录
- 将内存状态写入磁盘文件中（相对较快）
1.给那些内存数据做快照
-
redis数据都在内存中，执行全量快照，并记录到磁盘中
-
全量数据写入是个耗时操作，因此不应该阻塞在主线程上（阻塞操作主线程会影响效率）
-
操作
-
save 在主线程执行，导致阻塞\
-
bgsave 创建一个子进程，住纳闷用于RDB文件，避免主线程阻塞（默认配置）
-
-
在进行快照备份时，会不会影响到主线程操作
2.快照数据能修改吗
-
一方面，主线程等待快照生成（不能接受）
-
另一方面，只能读不能写（不能接受）
-
操作系统提供的COW（Copy-On-Write,）（读写+快照）
-
bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据\
-
取主线程的内存数据，并把它们写入 RDB 文件\
-
拷贝快照，只需要读取拷贝数据即可\
-
\
3.快照间隔
-
快照的间隔短，恢复就快
-
如果设置的很短，频繁执行会造成开销
- 全量数据写入磁盘，对磁盘压力较大，快照间在写磁盘时形成竞争关系
- fork操作从主进程创建过程会造成主进程阻塞，主进程内存越大，阻塞时间越长（redis只允许一个bgsave子进程）
-
增量快照
- 做了一次全量快照后，后续的快照只记录修改的数据
- 需要利用额外的元数据记录那些数据被修改了
- 但是为了记住修改，引入额外的开销有点得不偿失
-
快照恢复速度快很多，但是频率不好把握
-
Redis4.0中提出了一个混合使用AAOF日志和内存快照的方法
- 内存快照按照一定频率操作
- 两次快照间使用AOF日志记录所有命令操作
- RDB+AOF
\
4.总结
-
RDB Redis 用于避免数据丢失的内存快照方法
-
可以快速恢复数据库，也就是只需要把 RDB 文件直接读入内存，这就避免了 AOF 需要顺序、逐一重新执行操作命令带来的低效性能问题\
-
但是，频繁快照仍然是不太能接受的\
-
混合使用 RDB 和 AOF，正好可以取两者之长，避两者之短，以较小的性能开销保证数据可靠性和性能\
-
-
一些tips
-
数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；\
-
如果允许分钟级别的数据丢失，可以只使用 RDB；\
-
如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个平衡。
-
