Redis的强劲性能很大程度上是由于其将所有数据都存储在了内存中,为了使Redis在重启之后仍能保证数据不丢失,例如:
(1) 将Redis作为数据库使用(存储历史数据)。
(2) 将Redis作为缓存服务器使用,如果缓存被穿透后会对性能造成很大影响,所有缓存同时失效会导致缓存雪崩,从而使服务器无法响应。
这时,我们希望Redis能将数据从内存中以某种方式同步到硬盘中,当服务器重启后可以根据硬盘中的记录恢复数据,这一过程就是持久化。
写操作的流程
首先我们来看一下数据库在进行写操作时到底做了哪些事,主要有下面五个过程。
1.客户端向服务端发送写操作(数据在客户端的内存中)
2.数据库服务端接收到写请求的数据(数据在服务端的内存中)
3.服务端调用write(2) 这个系统调用,将数据往磁盘上写(数据在系统内存的缓冲区中)
4.操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)
5.磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)
写操作大致有上面5个流程,下面我们结合上面的5个流程看一下各种级别的故障。
•当数据库系统故障时,这时候系统内核还是OK的,那么此时只要我们执行完了第3步,那么数据就是安全的,因为后续操作系统会来完成后面几步,保证数据最终会落到磁盘上。
•当系统断电,这时候上面5项中提到的所有缓存都会失效,并且数据库和操作系统都会停止工作。所以只有当数据在完成第5步后,机器断电才能保证数据不丢失,在上述四步中的数据都会丢失。
通过上面5步的了解,可能我们会希望搞清下面一些问题:
•数据库多长时间调用一次write(2),将数据写到内核缓冲区
•内核多长时间会将系统缓冲区中的数据写到磁盘控制器
•磁盘控制器又在什么时候把缓存中的数据写到物理介质上
对于第一个问题,通常数据库层面会进行全面控制。而对第二个问题,操作系统有其默认的策略,但是我们也可以通过POSIX API提供的fsync系列命令强制操作系统将数据从内核区写到磁盘控制器上。对于第三个问题,好像数据库已经无法触及,但实际上,大多数情况下磁盘缓存是被设置关闭的。或者是只开启为读缓存,也就是写操作不会进行缓存,直接写到磁盘。建议的做法是仅仅当你的磁盘设备有备用电池时才开启写缓存。
所谓数据损坏,就是数据无法恢复,上面我们讲的都是如何保证数据是确实写到磁盘上去,但是写到磁盘上可能并不意味着数据不会损坏。比如我们可能一次写请求会进行两次不同的写操作,当意外发生时,可能会导致一次写操作安全完成,但是另一次还没有进行。如果数据库的数据文件结构组织不合理,可能就会导致数据完全不能恢复的状况出现。
这里通常也有三种策略来组织数据,以防止数据文件损坏到无法恢复的情况:
1.第一种是最粗糙的处理,就是不通过数据的组织形式保证数据的可恢复性。而是通过配置数据同步备份的方式,在数据文件损坏后通过数据备份来进行恢复。
2.另一种是在上面基础上添加一个操作日志,每次操作时记一下操作的行为,这样我们可以通过操作日志来进行数据恢复。因为操作日志是顺序追加的方式写的,所以不会出现操作日志也无法恢复的情况。
3.更保险的做法是数据库不进行老数据的修改,只是以追加方式去完成写操作,这样数据本身就是一份日志,这样就永远不会出现数据无法恢复的情况了。
针对上述数据库写操作流程及数据库文件组织策略,我们来认识Redis的持久化
Redis支持两种方式的持久化
一种是RDB(快照)方式,一种是AOF(追加文件)方式。可以单独使用其中一种或将二者结合使用。
RDB
RDB方式的持久化是通过快照(snapshotting)完成的,当符合一定条件时Redis会自动将内存中的所有数据生成一份副本并存储在硬盘上,这个过程即为“快照”。Redis会在一下几种情况下对数据进行快照:
- 根据配置规则进行自动快照。
- 用户执行save或者bgsave命令。
- 执行flushall命令。
- 执行复制时。
根据配置规则进行自动快照
你可以配置保存点,使Redis如果在每N秒后数据发生了M次改变就保存快照文件。例如下面这个保存点配置表示每60秒,如果数据发生了1000次以上的变动,Redis就会自动保存快照文件:
save 60 1000
保存点可以设置多个,Redis的配置文件就默认设置了3个保存点:
# 格式为:save <seconds> <changes>
# 可以设置多个。
save 900 1 #900秒后至少1个key有变动
save 300 10 #300秒后至少10个key有变动
save 60 10000 #60秒后至少10000个key有变动
如果想禁用快照保存的功能,可以通过注释掉所有"save"配置达到,或者在最后一条"save"配置后添加如下的配置:
save ""
文件路径和名称
默认Redis会把快照文件存储为当前目录下一个名为dump.rdb的文件。要修改文件的存储路径和名称,可以通过修改配置文件redis.conf实现:
# RDB文件名,默认为dump.rdb。
dbfilename dump.rdb
# 文件存放的目录,AOF文件同样存放在此目录下。默认为当前工作目录。
dir ./
用户执行save或者bgsave命令
除了让Redis进行自动快照外,当进行服务器重启,手动迁移以及备份的时候我们也需要手动执行快照操作,redis提供了两命令:
save 命令执行一个同步保存操作,将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
一般来说,在生产环境很少执行 SAVE 操作,因为它会阻塞所有客户端,保存数据库的任务通常由 BGSAVE 命令异步地执行。
bgsave 命令执行之后立即返回 OK ,然后 Redis fork 出一个新子进程,原来的 Redis 进程(父进程)继续处理客户端请求,而子进程则负责将数据保存到磁盘,然后退出。
客户端可以通过 LASTSAVE 命令查看最近一次成功执行快照的时间,返回一个unix时间戳。
Flushall命令
flushall清空整个 Redis 服务器的数据(删除所有数据库的所有 key )。注意:无论清空数据库的过程是否触发了自动快照条件,只要自动快照条件不为空,redis就会执行一次快照。例如:当定义快照条件为1秒内修改10000个键时进行快照,而是据库只有一个健,执行flushall也会触发快照,即使这一过程只有一个健被修改。当没有定义自动快照条件时,执行fluahall命令不进行快照。
执行复制
当设置了主从模式时,redis会在复制初始化时进行自动快照,即使没有自定义自动快照条件,并且没有手动执行过快照操作,也会生成RDB快照文件。
快照原理
1.redis 使用 fork 命令复制一份当前进程(父进程)的副本(子进程)
2.父进程继续接受并处理客户端发来的命令,而子进程开始将内存的数据存储写入硬盘的临时文件
3.当子进程写入完所有数据后调用将临时文件替换旧的 RDB 文件,到这里一次快照结束。
RBD 明显的不足就是一旦数据库出现崩溃之类的,RDB 里保存的数据可能不是最新的,从上次 RDB 到 redis 停机这段时间的数据可能会丢失。
AOF
Redis 将所有对数据库进行过写入的命令(及其参数)记录到 AOF 文件, 以此达到记录数据库状态的目的为了方便起见, 我们称呼这种记录过程为同步。
开启AOF方式持久化:
appendonly yes
AOF文件的保存位置和RDB文件位置相同,默认appendonly.aof,可通过appendfilename参数修改:
Appendfilename appendonly.aof
同步硬盘数据
根据“写的操作流程”可知,虽然每次执行更改数据库内存操作时,AOF都会将命令记录在AOF文件中,但是根据操作系统缓存机制,数据并没有真正地写入硬盘。一般来讲启用AOF的应用无法容忍这样的损失,这就需要Redis在写入AOF文件后主动将系统缓存同步到硬盘中。
Redis 可以通过appendfsync 参数设同步的时机:
#appendfsync always #每次执行都同步
appendfsync everysec #每秒执行一次同步,默认
#appendfsync no # 不主动同步操作,由操作系统决定(30秒一次)
Redis 允许同时开启AOF和RDB,重启时会使用AOF文件恢复数据,因为AOF方式可能丢失的数据更少。
从上面看出,RDB和AOF操作都是顺序IO操作,性能都很高。而同时在通过RDB文件或者AOF日志进行数据库恢复的时候,也是顺序的读取数据加载到内存中。所以也不会造成磁盘的随机读。
到底选择什么呢?下面是来自官方的建议:
通常,如果你要想提供很高的数据保障性,那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失,那么你可以仅使用RDB。
很多用户仅使用了AOF,但是我们建议,既然RDB可以时不时的给数据做个完整的快照,并且提供更快的重启,所以最好还是也使用RDB。
在数据恢复方面:
RDB的启动时间会更短,原因有两个:
一是RDB文件中每一条数据只有一条记录,不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。
另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的,不需要再进行数据编码工作,所以在CPU消耗上要远小于AOF日志的加载