详解Redis的持久化机制

下数据库在进行写操作时到底做了哪些事，主要有下面五个过程：

• 客户端向服务端发送写操作(数据在客户端的内存中)。
• 数据库服务端接收到写请求的数据(数据在服务端的内存中)。
• 服务端调用write这个系统调用，将数据往磁盘上写(数据在系统内存的缓冲区中)。
• 操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。
• 磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。

2. 故障分析

写操作大致有上面5个流程，当数据库系统故障时，这时候系统内核还是完好的。那么此时只要我们执行完了第3步，那么数据就是安全的，因为后续操作系统会来完成后面几步，保证数据最终会落到磁盘上。当系统断电时，这时候上面5项中提到的所有缓存都会失效，并且数据库和操作系统都会停止工作。所以只有当数据在完成第5步后，才能保证在断电后数据不丢失。

【补充】这里可能有几个疑问：

• 数据库多长时间调用一次write，将数据写到内核缓冲区?
• 内核多长时间会将系统缓冲区中的数据写到磁盘控制器?
• 磁盘控制器又在什么时候把缓存中的数据写到物理介质上?

对于***个问题，通常数据库层面会进行全面控制。

而对第二个问题，操作系统有其默认的策略，但是我们也可以通过POSIX API提供的fsync系列命令强制操作系统将数据从内核区写到磁盘控制器上。

对于第三个问题，看起来数据库已经无法触及，但实际上，大多数情况下磁盘缓存是被设置关闭的，或者是只开启为读缓存，也就是说写操作不会进行缓存，直接写到磁盘。建议的做法是仅仅当你的磁盘设备有备用电池时才开启写缓存。

3. 数据损坏

所谓数据损坏，就是数据无法恢复，上面我们讲的都是如何保证数据是确实写到磁盘上去，但是写到磁盘上可能并不意味着数据不会损坏。比如我们可能一次写请求会进行两次不同的写操作，当意外发生时，可能会导致一次写操作安全完成，但是另一次还没有进行。如果数据库的数据文件结构组织不合理，可能就会导致数据完全不能恢复的状况出现。

三种解决策略：

• 最粗糙的处理，就是不通过数据的组织形式保证数据的可恢复性。而是通过配置数据同步备份的方式，在数据文件损坏后通过数据备份来进行恢复。实际上MongoDB在不开启操作日志，通过配置Replica Sets时就是这种情况。
• 在上面基础上添加一个操作日志，每次操作时记一下操作的行为，这样我们可以通过操作日志来进行数据恢复。因为操作日志是顺序追加的方式写的，所以不会出现操作日志也无法恢复的情况。这也类似于MongoDB开启了操作日志的情况。
• 更保险的做法是数据库不进行旧数据的修改，只是以追加方式去完成写操作，这样数据本身就是一份日志，这样就永远不会出现数据无法恢复的情况了。实际上CouchDB就是此做法的优秀范例。

那么，redis又针对持久化提供了什么方式呢?

redis持久化的两种方式

redis提供了两种持久化的方式，分别是RDB(Redis DataBase)和AOF(Append Only File)。

RDB，简而言之，就是将存储的数据快照的方式存储到磁盘上，

AOF，则是将redis执行过的所有写指令记录下来，通过write函数追加到AOF文件的末尾。在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!