Redis持久化怎么实现

编辑: admin 分类: mysql 发布时间: 2023-06-10 来源:互联网

Redis是一种高级key-value数据库。它跟memcached类似,不过数据可以持久化,而且支持的数据类型很丰富。有字符串,链表,集 合和有序集合。支持在服务器端计算集合的并,交和补集(difference)等,还支持多种排序功能。

Redis持久化怎么实现

Redis支持RDB与AOF两种持久化机制,持久化可以避免因进程异常退出或down机导致的数据丢失问题,在下次重启时能利用之前的持久化文件实现数据恢复。

RDB持久化

RDB持久化是一种持久化方式,它通过创建压缩的二进制文件快照,保存特定时间点的完整数据。RDB持久化是Redis默认的持久化方式。RDB持久化的触发包括手动触发与自动触发两种方式。

手动触发

save, 在命令行执行save命令,将以同步的方式创建rdb文件保存快照,会阻塞服务器的主进程,生产环境中不要用 bgsave, 在命令行执行bgsave命令,将通过fork一个子进程以异步的方式创建rdb文件保存快照,除了fork时有阻塞,子进程在创建rdb文件时,主进程可继续处理请求

自动触发

在redis.conf中配置 save m n 定时触发,如 save 900 1表示在900s内至少存在一次更新就触发 主从复制时,如果从节点执行全量复制操作,主节点自动执行bgsave生成RDB文件并发送给从节点 执行debug reload命令重新加载Redis时 执行shutdown且没有开启AOF持久化 redis.conf中RDB持久化配置

# 只要满足下列条件之一,则会执行bgsave命令save 900 1 # 在900s内存在至少一次写操作save 300 10
save 60 10000# 禁用RBD持久化,可在最后加 save ""# 当备份进程出错时主进程是否停止写入操作stop-writes-on-bgsave-error yes# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu资源更贵rdbcompression no
登录后复制

AOF持久化

AOF(Append-Only-File)持久化即记录所有变更数据库状态的指令,以append的形式追加保存到AOF文件中。一种重写方式为: 当服务器重新启动时,可以使用AOF文件中记录的命令来恢复先前关闭时的数据库状态。

redis.conf中AOF持久化配置如下

# 默认关闭AOF,若要开启将no改为yesappendonly no# append文件的名字appendfilename "appendonly.aof"# 每隔一秒将缓存区内容写入文件 默认开启的写入方式appendfsync everysec# 当AOF文件大小的增长率大于该配置项时自动开启重写(这里指超过原大小的100%)。auto-aof-rewrite-percentage 100# 当AOF文件大小大于该配置项时自动开启重写auto-aof-rewrite-min-size 64mb
登录后复制

AOF持久化的实现包括3个步骤:

命令追加:将命令追加到AOF缓冲区 文件写入:缓冲区内容写到AOF文件 文件保存:AOF文件保存到磁盘 其中后两步的频率通过appendfsync来配置,appendfsync的选项包括

always, 每执行一个命令就保存一次,安全性最高,最多只丢失一个命令的数据,但是性能也最低(频繁的磁盘IO) everysec,每一秒保存一次,推荐使用,在安全性与性能之间折中,最多丢失一秒的数据 no, 依赖操作系统来执行(一般大概30s一次的样子),安全性最低,性能最高,丢失操作系统最后一次对AOF文件触发SAVE操作之后的数据 AOF通过保存命令来持久化,随着时间的推移,AOF文件会越来越大,Redis通过AOF文件重写来解决AOF文件不断增大的问题(可以减少文件的磁盘占有量,加快数据恢复的速度),原理如下:

调用fork,创建一个子进程

子进程读取当前数据库的状态来“重写”一个新的AOF文件(这里虽然叫“重写”,但实际并没有对旧文件进行任何读取,而是根据数据库的当前状态来形成指令)

主进程持续将新的变动同时写到AOF重写缓冲区与原来的AOF缓冲区中

主进程获取到子进程重写AOF完成的信号,调用信号处理函数将AOF重写缓冲区内容写入新的AOF文件中,并对新文件进行重命名,原子地覆盖原有AOF文件,完成新旧文件的替换

AOF的重写也分为手动触发与自动触发
手动触发: 直接调用bgrewriteaof命令
自动触发: 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积,默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小(aof_current_size)和上一次重写后AOF文件大小(aof_base_size)的比值。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&(aof_current_size - aof_base_size)/aof_base_size> = auto-aof-rewrite-percentage
登录后复制
RDB vs AOF

RDB与AOF两种方式各有优缺点。

RDB的优点:与AOF相比,RDB文件相对较小,恢复数据比较快(原因见数据恢复部分) RDB的缺点:服务器宕机,RBD方式会丢失掉上一次RDB持久化后的数据;使用bgsave fork子进程时会耗费内存。 AOF的优点: AOF只是追加文件,对服务器性能影响较小,速度比RDB快,消耗内存也少,同时可读性高。使用AOF会带来两个缺点:生成的文件相对较大,即使通过AOF重写,仍然会比较大;同时,恢复数据的速度也比RDB慢。 数据库的恢复

如果没有开启AOF持久化功能,在服务器启动时,将会阻塞主进程期间自动载入RDB文件。如果开启了AOF持久化功能,服务器则会优先使用AOF文件来还原数据库状态,因为AOF文件的更新频率通常比RDB文件的更新频率高,保存的数据更完整。

redis数据库恢复的处理流程如下,

在数据恢复方面,RDB的启动时间会更短,原因有两个:

在 RDB 文件中,每个数据项只有一个记录,不像 AOF 日志那样可能存在一个数据项有多个操作记录的情况。所以每条数据只需要写一次就行了,文件相对较小。

RDB 文件的存储格式和Redis数据在内存中的编码格式是一致的,不需要再进行数据编码工作,所以在CPU消耗上要远小于AOF日志的加载。

但是在进行RDB持久化时,fork出来进行dump操作的子进程会占用与父进程一样的内存,采用的copy-on-write机制,对性能的影响和内存的消耗都是比较大的。比如16G内存,Redis已经使用了10G,这时save的话会再生成10G,变成20G,大于系统的16G。这时候会发生交换,要是虚拟内存不够则会崩溃,导致数据丢失。所以在用redis的时候一定对系统内存做好容量规划。

RDB、AOF混合持久化

Redis从4.0版开始支持RDB与AOF的混合持久化方案。首先由RDB定期完成内存快照的备份,然后再由AOF完成两次RDB之间的数据备份,由这两部分共同构成持久化文件。这个方案的优势在于其充分利用了RDB加载速度快、备份体积小以及AOF记录数据丢失几率尽可能低的特点。缺点是兼容性差,一旦开启了混合持久化,在4.0之前的版本都不识别该持久化文件,同时由于前部分是RDB格式,阅读性较低。

开启混合持久化

aof-use-rdb-preamble yes
登录后复制

数据恢复加载过程就是先按照RDB进行加载,然后把AOF命令追加写入。

持久化方案的建议 如果Redis只是用来做缓存服务器,比如数据库查询数据后缓存,那可以不用考虑持久化,因为缓存服务失效还能再从数据库获取恢复。建议同时采用两种持久化方式,以提高数据的安全性。如果你可以容忍在灾难发生时数据丢失几分钟,那么可以仅使用RDB。一般的设计方法是 使用主从复制机制以解决持久化时所带来的性能影响。即Master上RDB、AOF都不做,保证Master的读写性能,而Slave上则同时开启RDB和AOF(或4.0以上版本的混合持久化方式)来进行持久化,保证数据的安全性。

【感谢龙石为本站提供api网关 http://www.longshidata.com/pages/apigateway.html】