什么是持久化，简单来讲就是将数据放到断电后数据不会丢失的设备中。也就是我们通常理解的硬盘上。
写操作的流程
首先我们来看一下数据库在进行写操作时到底做了哪些事，主要有下面五个过程。
- 客户端向服务端发送写操作（数据在客户端的内存中）
- 数据库服务端接收到写请求的数据（数据在服务端的内存中）
- 服务端调用 write (2) 这个系统调用，将数据往磁盘上写（数据在系统内存的缓冲区中）
- 操作系统将缓冲区中的数据转移到磁盘控制器上（数据在磁盘缓存中）
- 磁盘控制器将数据写到磁盘的物理介质中（数据真正落到磁盘上）
写操作大致有上面 5 个流程，下面我们结合上面的 5 个流程看一下各种级别的故障。
- 当数据库系统故障时，这时候系统内核还是 OK 的，那么此时只要我们执行完了第 3 步，那么数据就是安全的，因为后续操作系统会来完成后面几步，保证数据最终会落到磁盘上。
- 当系统断电，这时候上面 5 项中提到的所有缓存都会失效，并且数据库和操作系统都会停止工作。所以只有当数据在完成第 5 步后，机器断电才能保证数据不丢失，在上述四步中的数据都会丢失。
- 数据库多长时间调用一次 write (2)，将数据写到内核缓冲区
- 内核多长时间会将系统缓冲区中的数据写到磁盘控制器
- 磁盘控制器又在什么时候把缓存中的数据写到物理介质上
数据损坏
所谓数据损坏，就是数据无法恢复，上面我们讲的都是如何保证数据是确实写到磁盘上去，但是写到磁盘上可能并不意味着数据不会损坏。比如我们可能一次写请求会进行两次不同的写操作，当意外发生时，可能会导致一次写操作安全完成，但是另一次还没有进行。如果数据库的数据文件结构组织不合理，可能就会导致数据完全不能恢复的状况出现。
这里通常也有三种策略来组织数据，以防止数据文件损坏到无法恢复的情况：
- 第一种是最粗糙的处理，就是不通过数据的组织形式保证数据的可恢复性。而是通过配置数据同步备份的方式，在数据文件损坏后通过数据备份来进行恢复。实际上 MongoDB 在不开启 journaling 日志，通过配置 Replica Sets 时就是这种情况。
- 另一种是在上面基础上添加一个操作日志，每次操作时记一下操作的行为，这样我们可以通过操作日志来进行数据恢复。因为操作日志是顺序追加的方式写的，所以不会出现操作日志也无法恢复的情况。这也类似于 MongoDB 开启了 journaling 日志的情况。
- 更保险的做法是数据库不进行老数据的修改，只是以追加方式去完成写操作，这样数据本身就是一份日志，这样就永远不会出现数据无法恢复的情况了。实际上 CouchDB 就是此做法的优秀范例。
下面我们说一下 Redis 的第一个持久化策略，RDB 快照。Redis 支持将当前数据的快照存成一个数据文件的持久化机制。而一个持续写入的数据库如何生成快照呢。Redis 借助了 fork 命令的 copy _disibledevent=>AOF 日志。
AOF 日志
aof 日志的全称是 append _disibledevent=>appendfsync 选项来控制，下面 appendfsync 的三个设置项，安全强度逐渐变强。
appendfsync no
当设置 appendfsync 为 no 的时候，Redis 不会主动调用 fsync 去将 AOF 日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数 Linux 操作系统，是每 30 秒进行一次 fsync，将缓冲区中的数据写到磁盘上。
appendfsync everysec
当设置 appendfsync 为 everysec 的时候，Redis 会默认每隔一秒进行一次 fsync 调用，将缓冲区中的数据写到磁盘。但是当这一次的 fsync 调用时长超过 1 秒时。Redis 会采取延迟 fsync 的策略，再等一秒钟。也就是在两秒后再进行 fsync，这一次的 fsync 就不管会执行多长时间都会进行。这时候由于在 fsync 时文件描述符会被阻塞，所以当前的写操作就会阻塞。
所以，结论就是，在绝大多数情况下，Redis 会每隔一秒进行一次 fsync。在最坏的情况下，两秒钟会进行一次 fsync 操作。
这一操作在大多数数据库系统中被称为 group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。
appednfsync always
当设置 appendfsync 为 always 时，每一次写操作都会调用一次 fsync，这时数据是最安全的，当然，由于每次都会执行 fsync，所以其性能也会受到影响。
对于 pipelining 有什么不同
对于 pipelining 的操作，其具体过程是客户端一次性发送N个命令，然后等待这N个命令的返回结果被一起返回。通过采用 pipilining 就意味着放弃了对每一个命令的返回值确认。由于在这种情况下，N个命令是在同一个执行过程中执行的。所以当设置 appendfsync 为 everysec 时，可能会有一些偏差，因为这N个命令可能执行时间超过 1 秒甚至 2 秒。但是可以保证的是，最长时间不会超过这N个命令的执行时间和。
与 postgreSQL 和 MySQL 的比较
这一块就不多说了，由于上面操作系统层面的数据安全已经讲了很多，所以其实不同的数据库在实现上都大同小异。总之最后的结论就是，在 Redis 开启 AOF 的情况下，其单机数据安全性并不比这些成熟的 SQL 数据库弱。
数据导入
这些持久化的数据有什么用，当然是用于重启后的数据恢复。Redis 是一个内存数据库，无论是 RDB 还是 AOF，都只是其保证数据恢复的措施。所以 Redis 在利用 RDB 和 AOF 进行恢复的时候，都会读取 RDB 或 AOF 文件，重新加载到内存中。相对于 MySQL 等数据库的启动时间来说，会长很多，因为 MySQL 本来是不需要将数据加载到内存中的。
但是相对来说，MySQL 启动后提供服务时，其被访问的热数据也会慢慢加载到内存中，通常我们称之为预热，而在预热完成前，其性能都不会太高。而 Redis 的好处是一次性将数据加载到内存中，一次性预热。这样只要 Redis 启动完成，那么其提供服务的速度都是非常快的。
而在利用 RDB 和利用 AOF 启动上，其启动时间有一些差别。RDB 的启动时间会更短，原因有两个，一是 RDB 文件中每一条数据只有一条记录，不会像 AOF 日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。另一个原因是 RDB 文件的存储格式和 Redis 数据在内存中的编码格式是一致的，不需要再进行数据编码工作。在 CPU 消耗上要远小于 AOF 日志的加载。
好了，大概内容就说到这里。更详细完整的版本请看 Redis 作者的博文：Redis persistence demystified。本文如有描述不周之处，就大家指正。
最新评论