Redis持久化

Posted 2021-01-28 局部地区血淌

 对于Redis来说是存储在缓存之中的，因此缓存数据丢失问题一直是程序员们相当关注的话题，因此对缓存中的数据定时进行持久化的必要性就相当突出了，以下是Redis持久化的相关配置：

 

1  第一种: RDB持久化方式

 

1.1概述

默认redis是会以快照的形式将数据持久化到磁盘的（一个二进制文件，dump.rdb，这个文件名字可以指定），在配置文件中的格式是：save N M表示在N秒之内，redis至少发生M次修改则redis抓快照到磁盘。当然我们也可以手动执行save或者bgsave（异步）做快照。

 

1.2实现机制

当redis需要做持久化时，redis会fork一个子进程；子进程将数据写到磁盘上一个临时RDB文件中；当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处就是可以copy-on-write

 

1.3     相关配置

redis.conf配置文件：

1)

#  save ""

save 900 1    // 如果900秒内,有1条写入,则产生快照

save 300 10    // 如果300秒内有10次写入,则产生快照

save 60 10000    // 如果60秒内有10000次写入,则产生快照

2)

# The filename where to dump the DB

dbfilename dump.rdb     // 导出来的rdb文件名

3)

# Note that you must specify a directoryhere, not a file name.

dir ./    // rdb的放置路径

4)

stop-writes-on-bgsave-error yes

// 后台备份进程出错时,主进程停不停止写入?  主进程不停止 容易造成数据不一致

5)

rdbcompression yes

// 导出的rdb文件是否压缩    如果rdb的大小很大的话建议这么做

6)

Rdbchecksum yes

// 导入rbd恢复时数据时,要不要检验rdb的完整性 验证版本是不是一致

 

 在2个保存点之间,断电,将会丢失1-N分钟的数据 ,对于商业上面的应用，丢失的数据就是个disaster。     但是这个方式下 数据恢复的比较快

 

2  第二种:AOF持久化方式

 

2.1概述 append only file

还有一种持久化方法是Append-only：filesnapshotting方法在redis异常死掉时，最近的数据会丢失（丢失数据的多少视你save策略的配置），所以这是它最大的缺点，当业务量很大时，丢失的数据是很多的。Append-only方法可以做到全部数据不丢失，但redis的性能就要差些。AOF就可以做到全程持久化，只需要在配置文件中开启（默认是no），appendonly yes开启AOF之后，redis每执行一个修改数据的命令，都会把它添加到aof文件中，当redis重启时，将会读取AOF文件进行“重放”以恢复到redis关闭前的最后时刻。

LOG Rewriting随着修改数据的执行AOF文件会越来越大，其中很多内容记录某一个key的变化情况。因此redis有了一种比较有意思的特性：在后台重建AOF文件，而不会影响client端操作。在任何时候执行BGREWRITEAOF命令，都会把当前内存中最短序列的命令写到磁盘，这些命令可以完全构建当前的数据情况，而不会存在多余的变化情况（比如状态变化，计数器变化等），缩小的AOF文件的大小。所以当使用AOF时，redis推荐同时使用BGREWRITEAOF。

AOF文件刷新的方式，有三种，参考配置参数appendfsync ：appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件，非常非常慢，但也非常安全；appendfsynceverysec每秒钟都调用fsync刷新到AOF文件，很快，但可能会丢失一秒以内的数据；appendfsync no依靠OS进行刷新，redis不主动刷新AOF，这样最快，但安全性就差。默认并推荐每秒刷新，这样在速度和安全上都做到了兼顾。

可能由于系统原因导致了AOF损坏，redis无法再加载这个AOF，可以按照下面步骤来修复：首先做一个AOF文件的备份，复制到其他地方；修复原始AOF文件，执行：$ redis-check-aof –fix ;可以通过diff –u命令来查看修复前后文件不一致的地方；重启redis服务。

 

2.2实现机制

1)Redis将数据库做个快照，遍历所有数据库，将数据库中的数据还原为跟客户端发送来的指令的协议格式的字符串，

2)然后Redis新建一个临时文件将这些快照数据保存，待快照程序结束后将临时文件名修改为正常的aof文件名，原有的文件则自动丢弃。

由于在快照进行的过程中可能存在新增的命令修改了数据库中的数据，则在快照程序结束后需要将新修改的数据追加到aof文件中，后续的从客户端过来的命令都会不断根据不同的安全级别写到磁盘里面去。这样就支持了实时的持久化，只是可能会有短时间内的数据丢失，对一般系统还是可以容忍的。

 

2.3     相关配置

1)

appendonly no    // 是否打开aof日志功能

2)

appendfsync always    // 每1个命令,都立即同步到aof. 安全,速度慢

3)

appendfsync everysec    // 折衷方案,每秒写1次

4)

appendfsync no

// 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,

5)

no-appendfsync-on-rewrite yes

// 正在导出rdb快照的过程中,要不要停止同步aof

6)

auto-aof-rewrite-percentage 100

//aof文件大小比起上次重写时的大小,增长率100%时,重写

//缺点  刚开始的时候重复重写多次

7)

auto-aof-rewrite-min-size 64mb    // aof文件,至少超过64M时,重写

 

3  注意事项

 

注: 在dump rdb过程中,aof如果停止同步,会不会丢失?

答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作.

 

注: aof重写是指什么?

答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里.

以解决aof日志过大的问题.

 

问: 如果rdb文件,和aof文件都存在,优先用谁来恢复数据?

答: aof 

 

问: 2种是否可以同时用?

答: 可以,而且推荐这么做

 

问: 恢复时rdb和aof哪个恢复的快

答: rdb快,因为其是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行