最新公告
  • 欢迎您光临极客文库,本站秉承服务宗旨 履行“站长”责任,销售只是起点 服务永无止境!立即加入我们
  •  
    用过Redis的都知道,Redis有两种持久化方式:RDB和AOF,他们的区别大家应该都清楚,所以今天主要想分享一下这两种持久化方式的底层原理以及实现。
    如果让你手写一个持久化(架构级)的功能,你没有思路的话,那希望这个文章可以给你灵感。

    1. RDB持久化

    1.1 创建

    简单回顾下RDB文件的创建。
    有两种创建方式:
    1. save.阻塞进程去处理(期间不处理别的请求)
    2. bgsave.派生一个子进程去处理

    1.2 载入

    在redis服务启动时,如果检测到RDB文件,会进行自动载入。
    如果RDB文件和AOF都存在,优先载入谁?
    如果开启了AOF,则会优先AOF

    1.3 save的底层实现

    save 9001
    save 30010
    save 6010000
    这是redis.conf配置文件中关于RDB save时机的配置,它映射在redisServer结构体的saveparams字段中:
    structredisServer{
    ….
    // 保存了redis.conf配置的属性
    structsaveparam *saveparams;
    // 记录上一次save的时间
    time_t lastsave;
    // 修改计数器
    longlong dirty;
    };
    那来看看它怎么保存的:
    structsaveparam {
    // 秒数
    time_t seconds;
    // 修改次数
    int changes;
    };
    redis自己有一个定时任务每100毫秒执行一次,其中有一个任务就是检查save条件是否满足,如何判断的呢?就是用lastsavesaveparam.seconds比较时间是否满足,dirtychanges比较修改次数是否满足。
    那bgsave如何实现呢,new一个子线程,然后拷贝个数据副本,然后和save一样处理。
    好了,到这里,用Java写一个这应该是没问题了,那RDB的文件结构如何设计呢?我们来看看redis的设计。

    1.4 RDB文件结构

    REDIS+数据库版本号+数据类型+数据+EOF(表示数据结束)(377)+检验和
    我们知道java中Class文件结构很复杂,因为它包含了常量、接口、类、父类、字段等面向对象的信息,而RDB的就比较简单了,因为它只需要存放数据即可。
    和class结构一样,它的开头也是文件标识REDIS+版本号标识.
    [root@izuf6i2jk9azj2te13kjx8z redis-4.0.9]# od -c dump.rdb
    0000000 R E D I S 0008372 t r e d i s
    0000020 – v e r 0054 . 0 . 9372 n r e d i
    0000040 s – b i t s 300 @ 372005 c t i m e 302
    0000060231 ; 017 ] 372 b u s e d – m e m 302310
    0000100 p r 0372 f a o f – p r e a m b l
    0000120 e 300 0376 0373 ( 0 0006 k – 7599
    0000140006 v – 7599 0022 c p t : 254355 0
    0000160005 t 0 a g e t O n e 4303 L 220 ^ 303
    0000200037254355 0005 s r 0 % c o m . f a n
    0000220 t . c o r e . r e s p o n s e .
    0000240 S 005 e r v e r R 240016030222224 e 250 :
    0000260035323 ? 002 0003 I 0006 s t a t u s L
    0000300 0004 d a t 031 0022 L j a v a / l
    0000320 a n g / O b j e c t ; L 0003 m s
    0000340 g 340005032 f S t r i n g ; x p 0 0
    0000360 0310 y 0036340005 y 037 p o j o . C
    0000400 o m p e t i t i o n Z 276231334 b 025
    0140540 a 004 j a v a 377 v 006 n u m b e r 024
    0140560002 0 0 0006 0 0 0001 0002 0003 0004 0
    0140600005 0006 0016004 l i s t 001027027 0 0 0
    0140620024 0 0 0006 0 0362002363002364002365002366
    0140640002367377377022036 ] 367332257 _
    分析:
    R E D I S:RDB文件标志
    0008:版本号
    372:结束符
    r e d i s
    0000020 – v e r 0054 . 0 . 9:redis-version4.0.9
    r e d i
    0000040 s – b i t s 300 @:redis的位数6432
    c t i m e 3020000060231 ; 017 ]:时间戳
    u s e d – m e m 3023100000100 p r 0:redis使用内存的大小
    374RDB_OPCODE_EXPIRETIME_MS(带有过期时间标识)
    0: 表示字符串
    最后8字节为校验和
    更详细的可以查看http://redisbook.com/preview/rdb/rdb_struct.html
    手写过Jedis的朋友都熟悉RESP协议,RDB的数据段和它的排版方式很相似。比如: 003 m s g 005 h e l l o 377就表示键值对:msg(3个长度):hello(5个长度)

    AOF

    AOF以拼接和重写命令的方式来实现。
    # 是否开启aof
    appendonly yes
    # 文件名称
    appendfilename “appendonly.aof”
    # 同步方式
    ##每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用
    # appendfsync always
    ##每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,系统默认
    appendfsync everysec
    ##完全依赖os,性能最好,持久化没保证
    # appendfsync no
    # aof重写期间是否同步
    no-appendfsync-on-rewrite no
    # 重写触发配置
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb
    # 加载aof时如果有错如何处理
    aof-load-truncated yes
    # 文件重写策略
    aof-rewrite-incremental-fsync yes
    这一段配置中,大家着重理解同步方式的配置。redis默认采用的每秒一次写入AOF文件的策略。

    实现原理

    structredisServer{
    // ...
    // 存放AOF缓冲
    sds aof_buf;
    // ...
    };
    当有新的命令进来,redis就会将其(协议化后)追加到aof_buf的末尾。
    同理,redis的事件循环也会监听AOF的配置,如果满足配置文件中的同步方式appendfsync everysec等,就会将aof_buf中的内容保存到AOF文件里。

    为什么要进行AOF重写

    我们知道,redis对AOF有重写机制,用来控制AOF文件的大小。
    1. AOF体积过大不利于存储。
    2. AOF体积过大,使用AOF数据还原的时间更长。

    AOF重写多个键值对的数据一定是使用一条数据完成吗

    发生在重写列表、哈希表、集合、有序集合可能会带有多个元素的键时。
    不是,如果它的值超过64项,则会用多条命令来完成。(避免客户端输入缓冲区溢出)

    AOF谁来执行

    Redis不希望AOF重写造成服务器阻塞,所以用子进程(带有数据副本)去处理。

    AOF期间有新的数据进来会导致AOF文件与当前数据不一致吗

    不会。为了解决这个问题,Reids设置了AOF重写缓冲区(创建子进程后开启),当Redis执行命令时,redis会同时将这个信息发送给aof_buf和AOF重写缓冲区。

    扩展

    过期键的删除策略

    1. 定时删除。过期键较多的情况下,大量的CPU用于删除键而影响了客户端的请求。
    2. 惰性删除。只有过期键被访问才删除,可能会导致过期键过多,造成内存浪费和溢出。
    3. 定期删除。限制时长和频率对过期键进行删除,难点在于时长和频率难以确定。

    Redis的过期键删除策略

    Redis采用的是惰性删除和定期删除,配合这两种策略来取得CPU和内存的平衡。

    RDB和AOF文件中会包含过期键吗

    不包含。
    在生成RDB和AOF文件时,程序会对键进行检查,已过期的键不保存到文件中。
    本站所有文章均由网友分享,仅用于参考学习用,请勿直接转载,如有侵权,请联系网站客服删除相关文章。若由于商用引起版权纠纷,一切责任均由使用者承担
    极客文库 » Redis持久化深入理解

    常见问题FAQ

    免费下载或者VIP会员专享资源能否直接商用?
    本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
    提示下载完但解压或打开不了?
    最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量,若小于网盘提示的容量则是这个原因。这是浏览器下载的bug,建议用百度网盘软件或迅雷下载。若排除这种情况,可在对应资源底部留言,或 联络我们.。
    找不到素材资源介绍文章里的示例图片?
    对于PPT,KEY,Mockups,APP,网页模版等类型的素材,文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买,且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况,但部分素材会在素材包内有一份字体下载链接清单。
    极客文库
    程序员的加油站

    Leave a Reply

    Hi, 如果你对这款模板有疑问,可以跟我联系哦!

    联系发布者

    Leave a Reply

    Hi, 如果你对这款模板有疑问,可以跟我联系哦!

    联系发布者
    • 99会员总数(位)
    • 3629资源总数(个)
    • 44本周发布(个)
    • 0 今日发布(个)
    • 105稳定运行(天)

    欢迎加入「极客文库」,成为原创作者从这里开始!

    立即加入 了解更多