拆解 Redis 持久化 的工作原理
喜欢就 关注 我们吧！
简介：
Hello 各位 ，我是公号「八点半技术站」的创作者 - Bruce.D （姓氏：豆）。
感谢微信给予的个人认证，专注于PHP、数据库技术领域知识经验分享。
技术的交流、不仅仅限制于阅读，在此欢迎各路大神、小白，来「wx技术群」分享自己的编程经验心得 与 技术实战干货。
Redis 持久化如何工作？
Q：首先要知道什么是持久化？
A：持久化就是将数据放到断电后数据不会丢失的设备中。（通常理解的硬盘）
Q：redis 在进行写操作，做了哪些事？
A：
（1）客户端向服务端发送写操作（数据在客户端内存中）；
（2）数据库服务端接收到写请求数据（数据在服务端内存中）；
（3）服务端调用 write 这个系统调用，将数据往磁盘上写（数据在系统内存的缓冲区中）；
（4）操作系统将缓存区中的数据转移到磁盘控制器上（数据在磁盘缓存中）；
（5）磁盘控制器将数据写入到磁盘物理介质中（数据真正落到磁盘中）。
Redis 持久化 之 RDB
RDB 的这种方式、是将 redis 某一刻的数据持久化到磁盘中，是一种 快照式 的持久化方式。
redis 在进行数据持久化过程中，会将数据写入到一个临时的文件中，带持久化过程结束了，才会用这个临时文件替换上次那个持久化好的文件。
因为这种特性，我们可以随时备份数据，快照的文件总是完整可用的。
我们可以通过 redis 的 save 指令来配置 RDB快照生成时机，例如：配置当10分钟以内有100次写入就生成快照，可以多个规则一起生成 。
（注：这些规则定义在redis 配置文件中，也可通过 redis 的 CONFIG SET 命令在redis 设置规则，无需重启 redis ）
对于 RDB 方式，redis 会单独创建（fork）一个子进程进行持久化。
而主进程不会进行任何 IO 操作的，这样确保了redis 极高的性能。
redis 的 RDB 文件不会坏掉，因为在写操作时候是在一个新的进程中的，当生成一个新的RDB 文件时，redis 生成的子进程会将数据写到另外一个临时文件中，然后通过原子性 rename 系统调用临时文件重命名为 RDB 文件。
这样在任何时候出现故障，redis 的 RDB文件总是可用的。
RDB 有一个缺陷：
就是数据库一旦出现问题，RDB文件保存的数据不是全新的。从上次 RDB文件生成到 redis停机这段时间的数据全部丢失了。
在部分业务下，RDB 方式还是可以接受。如果无法忍受数据丢失应用，就可以采用另外一个机制 ：AOF 日志。
Redis 持久化 之 AOF
AOF 全称：Append Only File （日志文件）
AOF 的这种方式、只允许追加不允许改写的文件。
（注：AOF 文件是可识别纯文本，它的内容就是redis的标准命令）
它这种方式，是将执行过的写指令记录下来，数据恢复是按照从前到后的顺序再将指令全部执行一遍。
我们会通过配置 redis.conf 中的 appendonly yes 可以打开这个 AOF功能。如果有写操作，redis 就会被追加到 AOF文件的末尾。例如：
./redis-server --appendonly yes
开启后，查看 cat appendonly.aof 记录所有写操作都会生成一条相应命令作为日志。
（注：每一条写入命令生成一条日志，会导致 AOF文件越来越大，因此redis提供了一个功能— AOF rewrite - 重新生成一份AOF文件）
简单说一下 AOF rewrite：
重新生成一份 AOF文件，新的 AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了怼同一个值的多次操作。
默认的AOF持久化策略是：每秒钟 fsync 一次（fsync是指把缓存中的写指令记录到磁盘中）。因为这种情况下，redis 仍然可以保持很好的处理性能。即使 redis 故障，也只会丢失一秒的数据。
在追加日志时，恰好遇到磁盘空间满，或者断电等情况导致日志文件写入不完整，也是没有关系。redis 提供了 redis-check-aof 工具，可以进行日志修复。
到这里也就结束了，首先恭喜你又阅读完一篇文章，如果你认为有收获那么收藏转发起来，帮助需要的伙伴。
方案方式很多，就看你是否越意去研究、去发现，欢迎评论区留言~~~
往下拉，有干货
和我再战 n+1 天
同时，为了方便大家学习，我会把一些源码、技术干货存储到 github 中，随时可以在微信群 进行交流，扫下面二维码 ，备注 “技术进群” 就可以通过审核。
进群的小伙伴请加右侧私人微信（备注：技术进群）
----投稿分隔线----
投稿，关注公众号回复“投稿”，专员对接
-----商务合作分隔线----
商务合作，关注公众号回复“商务合作”，专员对接