Redis--配置文件、持久化之RDB、持久化之AOF
一、配置文件介绍
Redis 的配置文件位于 Redis 安装目录下,文件名为 redis.conf(Windows 名为 redis.windows.conf)。
你可以通过 CONFIG 命令查看或设置配置项。
语法
Redis CONFIG 命令格式如下:
redis 127.0.0.1:6379> CONFIG GET CONFIG_SETTING_NAME
实例
redis 127.0.0.1:6379> CONFIG GET loglevel
1) "loglevel"
2) "notice"
参数说明
redis.conf 配置项说明如下:
注意,下面配置项说明并不全,了解更多请检阅redis.conf。
| 序号 | 配置项 | 说明 |
|---|---|---|
| 1 | daemonize no |
Redis 默认不是以守护进程的方式运行,可以通过该配置项修改,使用 yes 启用守护进程(Windows 不支持守护线程的配置为 no ) |
| 2 | pidfile /var/run/redis.pid |
当 Redis 以守护进程方式运行时,Redis 默认会把 pid 写入 /var/run/redis.pid 文件,可以通过 pidfile 指定 |
| 3 | port 6379 |
指定 Redis 监听端口,默认端口为 6379,作者在自己的一篇博文中解释了为什么选用 6379 作为默认端口,因为 6379 在手机按键上 MERZ 对应的号码,而 MERZ 取自意大利歌女 Alessia Merz 的名字 |
| 4 | bind 127.0.0.1 |
绑定的主机地址 |
| 5 | timeout 300 |
当客户端闲置多长秒后关闭连接,如果指定为 0 ,表示关闭该功能 |
| 6 | loglevel notice |
指定日志记录级别,Redis 总共支持四个级别:debug、verbose、notice、warning,默认为 notice |
| 7 | logfile stdout |
日志记录方式,默认为标准输出,如果配置 Redis 为守护进程方式运行,而这里又配置为日志记录方式为标准输出,则日志将会发送给 /dev/null |
| 8 | databases 16 |
设置数据库的数量,默认数据库为0,可以使用SELECT 命令在连接上指定数据库id |
| 9 | save <seconds> <changes><br>Redis 默认配置文件中提供了三个条件:<br>save 900 1<br>save 300 10<br>save 60 10000<br> |
分别表示 900 秒(15 分钟)内有 1 个更改,300 秒(5 分钟)内有 10 个更改以及 60 秒内有 10000 个更改。<br>指定在多长时间内,有多少次更新操作,就将数据同步到数据文件,可以多个条件配合 |
| 10 | rdbcompression yes |
指定存储至本地数据库时是否压缩数据,默认为 yes,Redis 采用 LZF 压缩,如果为了节省 CPU 时间,可以关闭该选项,但会导致数据库文件变的巨大 |
| 11 | dbfilename dump.rdb |
指定本地数据库文件名,默认值为 dump.rdb |
| 12 | dir ./ |
指定本地数据库存放目录 |
| 13 | slaveof <masterip> <masterport> |
设置当本机为 slave 服务时,设置 master 服务的 IP 地址及端口,在 Redis 启动时,它会自动从 master 进行数据同步 |
| 14 | masterauth <master-password> |
当 master 服务设置了密码保护时,slav 服务连接 master 的密码 |
| 15 | requirepass foobared |
设置 Redis 连接密码,如果配置了连接密码,客户端在连接 Redis 时需要通过 AUTH <password> 命令提供密码,默认关闭 |
| 16 | maxclients 128 |
设置同一时间最大客户端连接数,默认无限制,Redis 可以同时打开的客户端连接数为 Redis 进程可以打开的最大文件描述符数,如果设置 maxclients 0,表示不作限制。当客户端连接数到达限制时,Redis 会关闭新的连接并向客户端返回 max number of clients reached 错误信息 |
| 17 | maxmemory <bytes> |
指定 Redis 最大内存限制,Redis 在启动时会把数据加载到内存中,达到最大内存后,Redis 会先尝试清除已到期或即将到期的 Key,当此方法处理 后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作。Redis 新的 vm 机制,会把 Key 存放内存,Value 会存放在 swap 区 |
| 18 | appendonly no |
指定是否在每次更新操作后进行日志记录,Redis 在默认情况下是异步的把数据写入磁盘,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为 redis 本身同步数据文件是按上面 save 条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认为 no |
| 19 | appendfilename appendonly.aof |
指定更新日志文件名,默认为 appendonly.aof |
| 20 | appendfsync everysec |
指定更新日志条件,共有 3 个可选值:<br>no:表示等操作系统进行数据缓存同步到磁盘(快)<br>always:表示每次更新操作后手动调用 fsync() 将数据写到磁盘(慢,安全)<br>everysec:表示每秒同步一次(折中,默认值)<br> |
| 21 | vm-enabled no |
指定是否启用虚拟内存机制,默认值为 no,简单的介绍一下,VM 机制将数据分页存放,由 Redis 将浏览量较少的页即冷数据 swap 到磁盘上,浏览多的页面由磁盘自动换出到内存中(在后面的文章我会仔细分析 Redis 的 VM 机制) |
| 22 | vm-swap-file /tmp/redis.swap |
虚拟内存文件路径,默认值为 /tmp/redis.swap,不可多个 Redis 实例共享 |
| 23 | vm-max-memory 0 |
将所有大于 vm-max-memory 的数据存入虚拟内存,无论 vm-max-memory 设置多小,所有索引数据都是内存存储的(Redis 的索引数据 就是 keys),也就是说,当 vm-max-memory 设置为 0 的时候,其实是所有 value 都存在于磁盘。默认值为 0 |
| 24 | vm-page-size 32 |
Redis swap 文件分成了很多的 page,一个对象可以保存在多个 page 上面,但一个 page 上不能被多个对象共享,vm-page-size 是要根据存储的 数据大小来设定的,作者建议如果存储很多小对象,page 大小最好设置为 32 或者 64bytes;如果存储很大大对象,则可以使用更大的 page,如果不确定,就使用默认值 |
| 25 | vm-pages 134217728 |
设置 swap 文件中的 page 数量,由于页表(一种表示页面空闲或使用的 bitmap)是在放在内存中的,,在磁盘上每 8 个 pages 将消耗 1byte 的内存。 |
| 26 | vm-max-threads 4 |
设置连接swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的,可能会造成比较长时间的延迟。默认值为4 |
| 27 | glueoutputbuf yes |
设置在向客户端应答时,是否把较小的包合并为一个包发送,默认为开启 |
| 28 | hash-max-zipmap-entries 64<br>hash-max-zipmap-value 512 |
指定在超过一定的数量或者最大的元素超过某一临界值时,采用一种特殊的哈希算法 |
| 29 | activerehashing yes |
指定是否激活重置哈希,默认为开启(后面在介绍 Redis 的哈希算法时具体介绍) |
| 30 | include /path/to/local.conf |
指定包含其它的配置文件,可以在同一主机上多个Redis实例之间使用同一份配置文件,而同时各个实例又拥有自己的特定配置文件 |
二、持久化之RDB
RDB(Redis DataBase)
是什么
- 在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里
- Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到 一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。 整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
Fork
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等) 数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程
- rdb 保存的是dump.rdb文件
- 相关配置在配置文件的位置 - 在redis.conf搜寻
### SNAPSHOTTING ### 
如何触发RDB快照
- 配置文件中默认的快照配置 默认名称
dbfilename "dump.rdb"- 冷拷贝后重新使用
- 命令 cp dump.rdb dump_new.rdb
- 冷拷贝后重新使用
- 命令save或者是bgsave
- Save:save时只管保存,立即保存,其它不管,全部阻塞
- BGSAVE:Redis会在后台异步进行快照操作, 快照同时还可以响应客户端请求。可以通过lastsave 命令获取最后一次成功执行快照的时间
- 执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义
如何恢复
- 将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可
CONFIG GET dir获取目录
RDB快照参数解析
优势与劣势
- 优势
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高
- 劣势
- 在一定间隔时间做一次备份,所以如果redis意外down掉的话,就 会丢失最后一次快照后的所有修改
- Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑
如何停止
动态所有停止RDB保存规则的方法:redis-cli config set save ""
小结

- RDB是一个非常紧凑的文件。
- RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他I0操作,所以RDB持久化方式可以最大化redis的性能。
- 与AOF相比,在恢复大的数据集的时候,RDB方式会更快一一些。
- 数据丢失风险大。
- RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候fork的过程是非常耗时的吗,可能会导致Redis在一些毫秒级不能回应客户端请求。
三、持久化之AOF
AOF(Append Only File)
是什么
以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录), 只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF配置
- 相关配置在配置文件的位置 - 在redis.conf搜寻
### APPEND ONLY MODE ### 默认配置no 
- aof保存的是appendonly.aof文件(在配置文件可修改文件名)



AOF启动/修复/恢复
- 正常恢复
- 启动:设置Yes
- 修改默认的appendonly no,改为yes
- 将有数据的aof文件复制一份保存到对应目录(config get dir)
- 恢复:重启redis然后重新加载
- 启动:设置Yes
- 异常恢复
- 启动:设置Yes
- 修改默认的appendonly no,改为yes
- 备份被写坏的AOF文件
- 修复:
- Redis-check-aof --fix进行修复
- 恢复:重启redis然后重新加载

- 启动:设置Yes
rewrite
- 是什么:
- AOF采用文件追加方式,文件会越来越大。为避免出现此种情况,新增了重写机制, 当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩, 只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof
- 重写原理
- AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename), 遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件, 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似
- 触发机制
- Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

-

优势与劣势
- 优势
- 每修改同步:appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
- 每秒同步:appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失
- 不同步:appendfsync no 从不同步
- 劣势
- 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
- Aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同
小结

- AOF文件时一个只进行追加的日志文件
- Redis可以在AOF文件体积变得过大时,自动地在后台对AOF进行重写
- AOF文件有序地保存了对数据库执行的所有写入操作,这些写入操作以Redis协议的格式保存,因此AOF文件的内容非常容易被人读懂,对文件进行分析也很轻松
- 对于相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积
- 根据所使用的fsync 策略,AOF的速度可能会慢于RDB
四、RDB和AOF的对比





浙公网安备 33010602011771号