Rides的持久化
RDB
RDB是rides默认持久化方式，以快照的方式将进程中的数据保存到磁盘，该持久化会生成一个被压缩过的".rdb"的二进制文件，内部存储了个数据库各键值信息，触发RDB持久化的方式又分为两种。
- 手动触发：通过用户执行SAVE命令或BGSAVE进行RDB持久化。
- 自动触发：通过配置触发，就是当服务器满足某些条件的时候执行BGSAVE命令。 其中在执行SAVE命令的时候，服务端会阻塞一直到.rdb文件创建完成。而BGSAVE是异步的SAVE命令，是由主进程fork一个子进程出来异步的去进行持久化操作（而在主进程fork子进程也会出现短暂阻塞）。
BGSAVE的原理COW（copy on write）:
RDB持久化的优势与缺点：
优点：RDB生成压缩的二进制文件，体积小，恢复数据的速度快
缺点：BGSAVE每次运行都要创建子进程，属于重量级操作，不宜频繁执行，因此RDB无法做到实时的持久化。
AOF
相对于RDB持久化解决了不可实时的这个缺陷。这也是现如今运用持久化的主流方式。AOF通过日志形式去记录，记录每一次写入的命令，重启时可以通过AOF文件恢复数据。AOF的工作流程可以分为：命令写入，文件同步，文件重写，重启加载。
说到这个地方我们又不得不提到AOF写入命令的方式。
文本协议格式的优缺点：
- 文本协议有很好的兼容性。
- 采用文本协议格式可以避免二次开销。
- 文本协议具有很好的可读性。
然后再聊一聊AOF持久化文件的同步机制： 在操作系统中当我们要写入文件时，通过write写入，系统就会对其优化，就是我们写入过程是写到缓冲区中，当缓冲区满了之后再flush到磁盘。
由于操作系统的优化过程会给我们带来很大的不确定性因此redis给我们提供了appendfsync选项。
| 取值 | 说明 |
|---|---|
| always | 就是我们没写入一个命令就将其flush到AOF文件，这样在redis挂了之后我们也就最多丢失一个命令 |
| everysec | 每间隔1秒钟，就冲洗一下AOF文件，最多丢失一秒钟的命令。 |
| no | 不主动对AOF文件Flush，有操作系统去决定何时flush。这个命令是最不可控制的，丢失情况也是相对最严重的 |
最后就聊一聊AOF的优缺点吧：
- 优点：相对于RDB持久化的方式安全性更高一点。而且我们可以通过appendsync选项去控制数据丢失的时间窗口限制在1秒以内。
- 缺点：AOF持久化是采用文本协议的方式，虽然可读性较好，但是其存储相对于'.rdb'文件来说占用空间更大，恢复时间更长。而且AOF在进行重写事也是需要fork子进程的，在数据较大的情况下会占用大量资源，会导致服务器短暂阻塞。
RDB-AOF混合型
这种就最有意思了，在redis4.0开始引入混合持久化的方式，这也是由AOF构建而来的。用户通过配置文件中的“aof-use0rdb-preamable yes ” 配置项来开启混合持久化。
