标签：AOF 持久 记录 Redis redis 快照 重写 数据
Redis 的数据持久化机制
Redis 的持久化主要有两大机制：AOF(Append Only File) 日志和 RDB 快照。
AOF
AOF 记录 Redis 的操作日志，它是在主线程中执行的。AOF 和数据库的写前日志(Write Ahead Log, WAL)不同，WAL 是在执行命令前先把修改的数据写到日志文件中，而 AOF 是在命令执行成功之后再记录日志，这样有两个好处：
- 可以减少额外的检查命令是否正确的开销。
- 因为是在命令执行后记录，所以不会阻塞当前的写操作。
AOF 日志的格式
AOF 中的命令是以文本形式记录的，以 “set testkey testvalue” 为例：Redis 会先以 *3 来表示当前命令有三个部分，每部分会先以 $+数字 来表示长度，然后跟上具体的命令、键或值。例如：
潜在风险
- 可能在命令执行之后，写入 AOF 之前机器宕机，那么相应数据就有丢失的风险。
- 上面说到 AOF 是在主线程执行的，如果磁盘写入很慢，那么就有可能阻塞下一个命令的执行。
写回策略
根据上述的潜在风险，Redis 提供了三种写回策略供用户评估选择，可以在 AOF 配置项 appendfsync 配置：
| 配置项 | 写回时间 | 优点 | 缺点 |
|---|---|---|---|
| Always | 同步写回 | 可靠性高，数据基本不丢失 | 每个写命令都要落盘，性能影响较大 |
| Everysec | 每秒写回 | 性能适中 | 宕机时丢失1秒内的数据 |
| No | 操作系统控制的写回 | 性能好 | 宕机时丢失数据较多 |
AOF 重写机制
背景
当 Redis 接收的命令越来越多，那么 AOF 文件就会越来越大，AOF 文件过大带来性能问题：
- 文件系统本身对文件大小有限制，无法保存过大的文件；
- 文件过大时，追加命令记录效率会变低；
- 如果发生宕机，AOF 中的记录要一个个回放恢复数据，文件过大时会导致这个过程非常缓慢，影响 Redis 的正常使用。
重写机制
重写机制是指 Redis 会根据当前的数据状态创建一个新的 AOF 文件，即读取当前 Redis 中的所有的记录，将其一一写入新的 AOF 文件中。
为什么重写机制可以缩小 AOF 文件的大小呢？正常使用过程中，使用者可能会对一个 key 进行多次操作，而这些操作都会被记录到 AOF 中，而重写机制会忽略这些过程，只将最后的结果记录到 AOF 中，多条记录合并成了一条。
重写过程和 AOF 日志不同，它是由后台子进程 bgrewriteaof 来完成的，这样可以避免阻塞主线程导致的性能下降。
重写过程的主要流程如下：
- 每次执行重写时，主线程会 fork 一个 bgrewiteaof 子进程，因为 fork 的特性，同时会把主进程的内存拷贝一份给子进程。
- 因为此时主线程没有被阻塞，AOF 日志还会正常执行。
- 主线程的操作还会被记录到重写缓冲区中，等拷贝数据重写完成后，重写缓冲区的日志也会被写入新的 AOF 文件，都完成后，新的 AOF 文件会替代就文件。
标签：AOF,持久,记录,Redis,redis,快照,重写,数据 来源： https://www.cnblogs.com/cyberbug/p/16548075.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。