【Redis】04_持久化原理

1 问题描述

1. 业务数据刚写入Mysql，开发者期望这些数据应该同步到Redis，但此时Redis服务挂了
2. Redis服务无故卡死，开发者期望重启Redis服务
3. …

以上情况，均需要考虑Redis的数据持久化机制，即考虑如何将内存数据持久化到硬盘。即使Redis服务挂了，Redis重启，也不会影响到业务数据的使用。

2 Redis持久化方式

1. rdb(Redis Database) 基于一定时间间隔保存那个时间点的数据快照。数据恢复时，直接将rdb文件(二进制文件)加载到内存中。持久化粒度是时间。
2. aof(Append Only File) 以追加的方式，将读写操作写入文件中。数据恢复时，执行aof文件中的读写操作以恢复数据。持久化粒度是每一个操作。
3. rdb+aof 两种方式都配置的情况，优先使用aof进行恢复，因为aof持久化的策略更加安全完整，且更新频率更高。

3 持久化原理

3.1 rdb方式

1. Redis提供两种创建rdb文件的方式，SAVE，BGSAVE
   - SAVE方式阻塞redis进程，期间redis无法接收我不请求。这种方式属于冷备份，确保数据一致性。
   - BGSAVE方式会创建出一个子进程，由子进程创建rdb文件，期间redis正常接收外部请求。

3.1.1 优点

1. rdb是一个二进制文件。恢复数据时，速度会更快。
2. 创建rdb的过程是由子进程操作的，不会影响redis服务处理外部请求。

3.1.2 缺点

1. 如果所需要保存的数据量很大，子进程花费的时间会更多，会占用一定的系统资源。
2. 备份间隔是基于时间而非写操作。在时间间隔内，redis还未来得及执行备份操作，redis服务挂了，此时数据丢失，产生了数据安全问题。

3.2 aof方式

针对rdb不能安全保存数据的问题，redis提供了aof的持久化方式。redis对每一个写操作记录都会存入aof文件，当恢复数据时，就一条条的执行aof中的记录已恢复数据。aof提供三种持久化方式。

1. appendfsync always
2. appendfsync everysec
3. appendfsync no

no: don't fsync, just let the OS flush the data when it wants. Faster.
always: fsync after every write to the append only log. Slow, Safest.
everysec: fsync only one time every second. Compromise.

3.2.1 优点

1. 如果使用appendfsync always持久化方式，数据安全性比rdb高

3.2.2 缺点

1. aof文件记录的是数据操作，因此从文件大小来说，同等数据集条件下aof文件比rdb大。
2. 如果使用appendfsync always持久化方式，每一个操作都需要主线程操作aof文件，redis性能会受影响

4 引用

• https://segmentfault.com/a/1190000002906345