Redis持久化方式RDB、AOF优缺点简述

Redis 基础数据类型：

String、Hash、List、Set、SrotSet；
String：数据类型为Key->Value；
Hash：数据类型对应Java -> Map 形式；
List：数据可重复，数组类型；
Set：数据结构类型 List，但数据不可重复；
SortSet：在 Set 数据结构上面，加上排序逻辑；

Redis 高级数据类型：

Bitmap、HyperLogLog、GEO

Redis 持久化存储方式：RDB、AOF

**RDB：【全量】**RDB持久化，是指在指定时间间隔将内存中的数据集快照存储写入到磁盘中。
实际操作过程是，fork 一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

RDB优点：

1、灵活设置备份的频率和周期。
2、适合冷备份，大批量数据的备份，对于灾难恢复而言，RDB是个不错的选择。
可非常轻松的将数据备份文件copy到其他存储介质上，进行大批量数据回复操作。
3、性能最大化。
对于 Redis 的服务进程而言，在开始持久化时，它唯一需要做的只是 fork 出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行 IO 操作了。也就是说，RDB 对 Redis 对外提供的读写服务，影响非常小，可以让 Redis 保持高性能
4、恢复更快速。
相比于 AOF 机制，RDB 的恢复速度更更快，更适合恢复数据，特别是在数据集非常大的情况。

RDB缺点：

1、如想保证数据的高可用性，其实就是备份数据准确性。那么RDB无法支持到实时的备份，只是一个时间段内的数据备份。如在RDB还没备份之前，系统出现宕机情况，那么还没写入磁盘的数据，将丢失。（结合AOF机制，配合使用）
2、RDB备份机制，是通过一个fork子进程来进行协助数据的持久化，在持久化的过程中，将会暂停所有的redis的数据集的操作，如果redis的数据集庞大，那么将有可能导致redis停止对外服务几百毫秒，或者是1秒。（建议尽量在系统访问量较低的情况下，进行备份）

**AOF：【增量】**AOF持久化，实际上就是将数据集以日志的写入方式，将数据写入到日志文件中{写、删除}，查询操作不写入其中。

AOF优点：

1、AOF是基于日志模式记录数据操作，所以该操作可以更加好的保证数据的安全性。
2、AOF日志写入记录操作模式为 append 模式，所以在使用过程中，即使服务器出现的宕机情况，也不会破坏redis 的日志文件内容。
3、如果 AOF 日志过大，Redis 可以自动启用 rewrite 机制。
即使出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。
4、AOF 包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作

AOF缺点：

1、针对相同数据量大小的恢复数据操作，建议使用RDB恢复，因相同数据大小情况下，RDB恢复速度比AOF恢复更快。
2、根据同步策略的不同，AOF 在运行效率上往往会慢于 RDB 。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和 RDB 一样高效。

如果哪位同学觉得我表述的有问题，欢迎提出建议哈，共同进步。