我是
方圆，励志成为一名优秀博主
方便浏览和索引 ↓
1. RDB
首先，我们必须清楚的一点，
Redis是内存数据库，如果不进行持久化，服务器在宕机或退出的时候，数据就会丢失，所以需要实现持久化
1.1 RDB实现过程
RDB的实现是先fork出一个子进程，在指定的时间间隔内将内存中的数据集快照写入临时文件中，写入成功后，覆盖最终的RDB文件，用二进制压缩存储。RDB也是Redis默认的持久化机制。
1.2 RDB文件的生成机制
- 满足 save 的条件（配置文件中查看sava 条件）
- flushall命令执行后，会创建RDB文件
- 退出Redis，也会生成rdb文件
1.3 RDB优缺点
- 优点
RDB在恢复大数据集时，相比于AOF恢复速度快- RDB文件是一个非常紧凑的文件，
它保存了 Redis 在某个时间点上的数据集, 这种文件非常适合用于进行备份
- 缺点
- 若
在save的过程中服务器宕机，那么数据会丢失 - Redis需要fork出一个子进程，在数据量很大情况下，会很耗时
2. AOF
2.1 AOF实现过程
AOF持久化的实现，是将所有的写命令都记录下来，以aof文件的形式进行记录（在aof文件中，我们可以看到具体的命令），在redis启动之后，会读取该文件，重新构建出内存中的数据，默认情况下AOF机制是关闭的，需要使用的时候需要进行配置
2.2 AOF文件生成条件
可以在配置文件中进行配置
appendfsync always AOF持久化频率 持续
appendfsync everysec AOF持久化频率 每秒
appendfsync no AOF持久化频率 write后不会有fsync调用，由操作系统自动调度刷磁盘，性能是最好的
2.3 AOF文件出现问题
当我们对AOF文件进行了不规范修改，或者AOF文件本身出现了问题，我们是无法连上Redis的，只能选择退出，并使用redis-check-aof工具对aof文件进行检查后，才能重新连接Redis。
在bin目录下，我们能找到这个工具
2.4 AOF优缺点
- 优点
- AOF 的默认策略为每秒钟fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也
最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求） - Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：
重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合
- 缺点
- 在
大数据量的时候，数据恢复比较慢 - 对于相同的数据集，AOF文件大小大于RDB文件
根据所使用的 fsync策略，AOF的速度可能会慢于RDB 。 在一般情况下，每秒fsync的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。
3. RDB和AOF我们该如何进行选择
小孩子才做选择，大人全都要
若想实现最佳的性能和数据安全，一般来说，应该同时使用两种持久化功能。
默认情况下是RDB持久化机制，而且大多是情况下RDB持久化机制能够满足我们的需求，也代表我们必须要能够接受数分钟以内的数据丢失的可能。
在对数据没有特别严格的完整性要求的情况下，不推荐单独使用AOF持久化机制，因为AOF读取数据相比于RDB慢，而且RDB还非常方便文件备份。
参考
该系列其他文章
Redis之必备基础知识点，文读百变其意自现（一）
Redis之数据类型，好记性不如烂笔头（二）
Redis之事务乐观锁和Jedis，谁说的Redis不能实现乐观锁的？（三）
Redis之redis.conf解析，了解了这些配置信息，才能说了解Redis（四）
Redis之主从复制和哨兵模式，差不多儿啦（五）
