Redis核心技术与实战
蒋德钧
中科院计算所副研究员
新⼈⾸单¥29.9
6063 人已学习
课程目录
已更新 11 讲 / 共 50 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 这样学Redis,才能技高一筹
免费
基础篇 (10讲)
01 | 基本架构:一个键值数据库包含什么?
02 | 数据结构:快速的Redis有哪些慢操作?
03 | 高性能IO模型:为什么单线程Redis能那么快?
04 | AOF日志:宕机了,Redis如何避免数据丢失?
05 | 内存快照:宕机后,Redis如何实现快速恢复?
06 | 数据同步:主从库如何实现数据一致?
07 | 哨兵机制:主库挂了,如何不间断服务?
08 | 哨兵集群:哨兵挂了,主从库还能切换吗?
09 | 切片集群:数据增多了,是该加内存还是加实例?
10 | 第1~9讲课后思考题答案及常见问题答疑
Redis核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

06 | 数据同步:主从库如何实现数据一致?

蒋德钧 2020-08-17
你好,我是蒋德钧。
前两节课,我们学习了 AOF 和 RDB,如果 Redis 发生了宕机,它们可以分别通过回放日志和重新读入 RDB 文件的方式恢复数据,从而保证尽量少丢失数据,提升可靠性。
不过,即使用了这两种方法,也依然存在服务不可用的问题。比如说,我们在实际使用时只运行了一个 Redis 实例,那么,如果这个实例宕机了,它在恢复期间,是无法服务新来的数据存取请求的。
那我们总说的 Redis 具有高可靠性,又是什么意思呢?其实,这里有两层含义:一是数据尽量少丢失,二是服务尽量少中断。AOF 和 RDB 保证了前者,而对于后者,Redis 的做法就是增加副本冗余量,将一份数据同时保存在多个实例上。即使有一个实例出现了故障,需要过一段时间才能恢复,其他实例也可以对外提供服务,不会影响业务使用。
多实例保存同一份数据,听起来好像很不错,但是,我们必须要考虑一个问题:这么多副本,它们之间的数据如何保持一致呢?数据读写操作可以发给所有的实例吗?
实际上,Redis 提供了主从库模式,以保证数据副本的一致,主从库之间采用的是读写分离的方式。
读操作:主库、从库都可以接收;
写操作:首先到主库执行,然后,主库将写操作同步给从库。
Redis主从库和读写分离
那么,为什么要采用读写分离的方式呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Redis核心技术与实战》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥29.9
立即订阅
登录 后留言

精选留言(44)

  • Geek_121747 置顶
    老师,我对repl_backlog_buffer有点疑问,

    文中描述1:“因为 repl_backlog_buffer 是一个环形缓冲区,所以在缓冲区写满后,主库会继续写入,此时,就会覆盖掉之前写入的操作。如果从库的读取速度比较慢,就有可能导致从库还未读取的操作被主库新写的操作覆盖了,这会导致主从库间的数据不一致。”

    文中描述2:我特别建议你留意一下 repl_backlog_size 这个配置参数。如果它配置得过小,在增量复制阶段,可能会导致从库的复制进度赶不上主库,进而导致从库重新进行全量复制。

    我的疑问是,如果在网络断开期间,repl_backlog_size环形缓冲区写满之后,从库是会丢失掉那部分被覆盖掉的数据,还是直接进行全量复制呢?

    作者回复: 我看到还有几个同学在问类似的这个问题,大家都思考的很仔细,非常好!

    对于这个问题来说,有两个关键点:
    1. 一个从库如果和主库断连时间过长,造成它在主库repl_backlog_buffer的slave_repl_offset位置上的数据已经被覆盖掉了,此时从库和主库间将进行全量复制。

    2. 每个从库会记录自己的slave_repl_offset,每个从库的复制进度也不一定相同。在和主库重连进行恢复时,从库会通过psync命令把自己记录的slave_repl_offset发给主库,主库会根据从库各自的复制进度,来决定这个从库可以进行增量复制,还是全量复制。

    2020-08-17
    1
    19
  • Kaito
    主从全量同步使用RDB而不使用AOF的原因:

    1、RDB文件内容是经过压缩的二进制数据(不同数据类型数据做了针对性优化),文件很小。而AOF文件记录的是每一次写操作的命令,写操作越多文件会变得很大,其中还包括很多对同一个key的多次冗余操作。在主从全量数据同步时,传输RDB文件可以尽量降低对主库机器网络带宽的消耗,从库在加载RDB文件时,一是文件小,读取整个文件的速度会很快,二是因为RDB文件存储的都是二进制数据,从库直接按照RDB协议解析还原数据即可,速度会非常快,而AOF需要依次重放每个写命令,这个过程会经历冗长的处理逻辑,恢复速度相比RDB会慢得多,所以使用RDB进行主从全量同步的成本最低。

    2、假设要使用AOF做全量同步,意味着必须打开AOF功能,打开AOF就要选择文件刷盘的策略,选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量同步数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景,其实是不需要开启AOF的。

    另外,需要指出老师文章的错误:“当主从库断连后,主库会把断连期间收到的写操作命令,写入 replication buffer,同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。”

    1、主从库连接都断开了,哪里来replication buffer呢?

    2、应该不是“主从库断连后”主库才把写操作写入repl_backlog_buffer,只要有从库存在,这个repl_backlog_buffer就会存在。主库的所有写命令除了传播给从库之外,都会在这个repl_backlog_buffer中记录一份,缓存起来,只有预先缓存了这些命令,当从库断连后,从库重新发送psync $master_runid $offset,主库才能通过$offset在repl_backlog_buffer中找到从库断开的位置,只发送$offset之后的增量数据给从库即可。

    有同学对repl_backlog_buffer和replication buffer理解比较混淆,我大概解释一下:

    1、repl_backlog_buffer:就是上面我解释到的,它是为了从库断开之后,如何找到主从差异数据而设计的环形缓冲区,从而避免全量同步带来的性能开销。如果从库断开时间太久,repl_backlog_buffer环形缓冲区被主库的写命令覆盖了,那么从库连上主库后只能乖乖地进行一次全量同步,所以repl_backlog_buffer配置尽量大一些,可以降低主从断开后全量同步的概率。而在repl_backlog_buffer中找主从差异的数据后,如何发给从库呢?这就用到了replication buffer。

    2、replication buffer:Redis和客户端通信也好,和从库通信也好,Redis都需要给分配一个 内存buffer进行数据交互,客户端是一个client,从库也是一个client,我们每个client连上Redis后,Redis都会分配一个client buffer,所有数据交互都是通过这个buffer进行的:Redis先把数据写到这个buffer中,然后再把buffer中的数据发到client socket中再通过网络发送出去,这样就完成了数据交互。所以主从在增量同步时,从库作为一个client,也会分配一个buffer,只不过这个buffer专门用来传播用户的写命令到从库,保证主从数据一致,我们通常把它叫做replication buffer。

    3、再延伸一下,既然有这个内存buffer存在,那么这个buffer有没有限制呢?如果主从在传播命令时,因为某些原因从库处理得非常慢,那么主库上的这个buffer就会持续增长,消耗大量的内存资源,甚至OOM。所以Redis提供了client-output-buffer-limit参数限制这个buffer的大小,如果超过限制,主库会强制断开这个client的连接,也就是说从库处理慢导致主库内存buffer的积压达到限制后,主库会强制断开从库的连接,此时主从复制会中断,中断后如果从库再次发起复制请求,那么此时可能会导致恶性循环,引发复制风暴,这种情况需要格外注意。
    2020-08-17
    40
    97
  • Geek_121747
    每课一问:1.因为AOF文件比RDB文件大,网络传输比较耗时,
                  2.从库在初始化数据时,RDB文件比AOF文件执行更快
    2020-08-17
    8
  • Darren
    上一条评论有误,已经删除,请通过本条评论

    repl_backlog_size这个参数很重要,因为如果满了,就需要重新全量复制,默认是1M,所以之前网上就流传1个段子,如果一个公司说自己体量如何大,技术多么牛,要是repl_backlog_size参数是默认值,基本可以认为要不业务体量吹牛逼了,要不就没有真正的技术牛人。

    主从复制的另一种方式:基于硬盘和无盘复制
    可以通过这个参数设置
    repl-diskless-sync
    复制集同步策略:磁盘或者socket
    新slave连接或者老slave重新连接时候不能只接收不同,得做一个全同步。需要一个新的RDB文件dump出来,然后从master传到slave。可以有两种情况:
     1)基于硬盘(disk-backed):master创建一个新进程dump RDB,完事儿之后由父进程(即主进程)增量传给slaves。
     2)基于socket(diskless):master创建一个新进程直接dump RDB到slave的socket,不经过主进程,不经过硬盘。

    当基于 disk-backed 复制时,当 RDB 文件生成完毕,多个 replicas 通过排队来同步 RDB 文件。

    当基于diskless的时候,master等待一个repl-diskless-sync-delay的秒数,如果没slave来的话,就直接传,后来的得排队等了。否则就可以一起传。适用于disk较慢,并且网络较快的时候,可以用diskless。(默认用disk-based)


    回答下课后问题:
        1、RDB读取快,这样从库可以尽快完成RDB的读取,然后入去消费replication buffer的数据。如果是AOF的话,AOF体积大,读取慢,需要更大的replication buffer,如果一个主节点的从节点多的话,就需要更大的内存去处理;
        2、AOF文件是append追加模式,同时读写需要考虑并发安全问题,并且AOF是文本文件,体积较大,浪费网络带宽。

    最后问老师个问题哈,就是bgsave生成的rdb文件什么时候“过期”,或者有过期的说法吗?比如我2个从节点执行replicaof(或者slaveof),主节点是同一个,这中情况下,rdb生成1次还是2次?
    2020-08-17
    1
    7
  • Geek_33c084
    主从复制的流程:1.建立链接;2.rdb全量复制;2.网络长链接复制。
    主-从-从的级联主从复制模式:减少主库的bgsave压力,减少网络传输的压力
    断网重连:repl_backlog_size环形缓冲区,存在覆盖情况。主库还可以根据slave_repl_offset判断是全量复制,还是增量复制

    作者回复: 不错的总结!

    2020-08-18
    2
  • QFY
    课后题:
    aof记录的是命令,如果是首次主从全量复制,而且如果aof文件还没被重写会存在对一个key的反复操作,那么效率会比较低

    疑问:
    【repl_backlog_buffer 是一个环形缓冲区,主库会记录自己写到的位置,从库则会记录自己已经读到的位置】针对这一句,这个repl_backlog_buffer是在主库上面,但是他同时要记录master_repl_offset和slave_repl_offset,这个slave_repl_offset是每个从库记录一个还是共用一个?如果是共用一个,那如果有两个从库正在恢复,一个正常恢复把slave_repl_offset往前推了,另一个从库在恢复的过程中又断了,但是再恢复的时候slave_repl_offset已经往前推了,中间就有一部分数据丢失了,这个情况该怎么办了(这个情况可能有点极端)

    作者回复: 善于思考,非常棒!

    repl_backlog_buffer是所有从库共享的,不过正如文章中说的,slave_repl_offset是由从库自己记录的,这也是因为每个从库的复制进度不一定相同。

    从库断连后再恢复时,会给主库发送psync命令,并把自己当前的slave_repl_offset发给主库。所以,在你所说的情况下,正常恢复的从库推进的slave_repl_offset是它自己记录的,不会影响到第二个从库。

    第二个从库断连后再恢复,只要slave_repl_offset指向的数据没有被覆盖,就能继续恢复。

    希望解答了你的问题 :)

    2020-08-17
    1
    2
  • tt
    我觉得之所以主从库间的数据复制同步使用的是 RDB 文件,是因为主从复制要解决的是不同节点之间状态的一致性问题,RDB文件的内容正好是某一个时间点主库的状态

    AOF文件则不同,其内容本质上是操作而不是状态,内容存在大量冗余。主从复制本质上是一个最终一致性的过程,为了减少不一致的时间窗口的大小,采用RDB文件是最合适的。
    2020-08-17
    2
  • test
    课后题:aof比rdb大,rdb加载起来比aof快。
    2020-08-17
    2
  • 赖阿甘
    我有个疑问,为什么要有两个缓冲区,replication buffer和repl_backlog_buffer ,这两个缓冲区的区别是什么?replication buffer缓冲区是每个从库的连接都有一个吗?按照我的理解,replication buffer在第一次连接时完成全量复制(包括复制期间主库又接收到的新操作),进入长连接复制之后这个缓冲区就应该没有作用了,但是为什么主从断联之后,主库还要把接受到的写命令都记录到这两个缓冲区,照理说只需要记录到repl_backlog_buffer就可以了,还望老师解答
    2020-08-17
    1
    2
  • 不负青春不负己🤘
    我问个问题 psync 这个动作 执行 RDB 全量数据,是直接传输到从库上,还是先落到主redis 磁盘上

    作者回复: Redis在全量复制时,既支持先生成RDB文件,再把RDB文件传给从库,也支持在主库上直接通过socket把数据传给从库,这称为无盘复制。

    如果运行主库的机器磁盘性能不太好,但是网络性能不错的话,可以考虑无盘复制。

    2020-08-18
    1
  • 我有个疑问,redis我记得是AOF和RDB只能选择一个,要么开启AOF,要么开启RDB,如果master开启了AOF,那这是的RDB又怎么开启的呢?还是说master会同时开启AOF和RDB?

    作者回复: Redis中RDB是默认开启的。同时,你可以在配置文件中设置appendonly yes,这样就可以把AOF也开启了。

    在RDB和AOF同时开启后,在进行恢复时,会优先使用AOF进行恢复。

    2020-08-18
    1
  • 曾轼麟
    使用RDB主要是有以下几个原因:
    1、首先RDB和AOF最大的区别就是,RDB是内存快照,而AOF记录的是数据变化的过程,在全量初始化的情况下肯定是快照更优,RDB作为数据初始化的方式也更加快
    2、是针对RDB和AOF的文件大小问题,AOF是数据变化的过程(动态变化),相比于RDB不利于压缩,使用RDB在传输文件的时候可以更好的节约网络资源
    3、进行主从同步并不是只使用RDB,而是RDB + 缓冲区的方式,这样可以保证bgsave期间的数据任然能同步

    在生产环境中主从复制会经常出现以下两种情况:1、从服务器重启,2、主服务器宕机
    在早期Redis中每次出现意外进行重新同步都是使用RDB的方式(sync),会导致很大的开销,于是在Redis2.8开始实现了部分重同步的功能psync
    psync 的格式如下:psync <Master-Run-ID> <OFFSET> ,通过缓冲区 + offset的方式来避免每次进行完全重同步

    为了保证数据的最终一致性现如今Redis也具备两种同步方式:
    1、完全重同步(RDB同步)
    2、部分重同步(缓冲区同步)

    【完全重同步】的开销是很大的(走bgsave),生产环境中希望尽可能的使用【部分重同步】,但是【部分重同步】的条件也比较苛刻条件如下:
    1、从服务器两次执行 RUN_ID 必须相等
    2、复制偏移量必须包含在复制缓冲区中

    也由于这些原因,Redis4.0的时候提出了psync2的方式,主要改进点在两个方面:
    1、RDB文件中用于存放辅助字段的 AUX_FIELD_KEY_VALUE_PAIRS 中保存主服务器的RUN_ID,当从服务器恢复的时候能避免进行完全重同步
    2、在新易主的服务器中冗余上一个主服务器的RUN_ID 和 offset 分别存放在 server.replid2 和 server.second_replid_offset 这两个字段中,这样避免主从切换后发生完全重同步
    2020-08-18
    1
  • 王聪
    看了课程内容,不看评论绝对是一种损失

    作者回复: 咱们评论区有不少同学的回复都很棒,思考问题非常仔细、周全和深入。

    读评论区是一次非常好的再学习过程 :)

    2020-08-17
    1
  • Monday
    repl_backlog_buffer是以从库为粒度保存的吧,也就说在一主多从的情况下,主会分别保存多每个从库的处理位置吧。
    思考题:
    1、rdb比aof通常情况下会大些,
    2、传播起来更耗带宽等资源
    3、从库恢复更耗时间

    作者回复: 如果“以从库为粒度保存”是指每个从库有自己的复制位置,那就没问题。

    我也再解释下,repl_backlog_buffer就是一块内存空间,被所有从库共享的。不过每个从库会记录自己的复制位置,重新同步时也会发给主库。

    2020-08-17
    1
    1
  • 醉、随风🙄 🙄
    我有个问题,为什么一定要同时存在repl_backlog_buffer和replication buffer两个缓冲区,而且repl_backlog_buffer确要定义成环形的。我觉得是否可以定义成一个链表,然后主库的offset与从库的offset都指向链表中某个元素,redis定时清理从库offset之前的数据,这样不是做到了既能增量同步,也不用担心因为并发过大造成的同步数据丢失。
    2020-08-17
    1
    1
  • 猿人谷
    补充一个知识点:主从模式下,Redis能否读到过期键?
    当 Redis 运行在主从模式下时,从库不会进行过期扫描,从库对过期键的处理是被动的。也就是即使从库中的 key 过期了,如果有客户端访问从库时,依然可以得到 key 对应的值,像未过期的键值对一样返回。
    2020-08-17
    1
    1
  • Mr.蜜
    我有一个疑问,环形缓冲期再大,也会出问题,那么如果遇到这类问题,导致数据不同步怎么处理?比方说,一个从库长断网以后,长时间没有联网处理。

    作者回复: 没错,环形缓冲区再大,在某些时候,就如你所说的从库长期断网时,也会出问题。

    其实从库正常情况下会每秒给主库发送一个replconf ack命令,主库会根据这个命令的达到时间判断和从库的连网情况。如果距离最后一次ack命令收到的时间已经超过了repl_timeout时间,就会和从库断开连接了。

    从库再和主库连接时,会发送自己的复制进度,如果要复制内容在缓冲区中已经被覆盖了,那么就不再做增量复制了,而是进行全量复制。

    2020-08-17
    1
  • Jackey
    印象中Redis在repl_backlog_buffer写满了之后会触发一次全量复制,以此来保证被覆盖的数据不丢失。不知道对不对
    2020-08-17
    1
    1
  • 等风来🎧
    如果并大量特别大,增量复制的时候,从库的消费的偏移量仍不在主库的环形缓存池中,应该会进行一次全量复制,这个老师好像没有提到

    作者回复: 咱们有同学问到了类似slave_repl_offset被覆盖的这个问题,你的回复就是答案。 :)

    我在文章小结中有提到了一句“通过调大这个参数(repl_backlog_size),可以减少从库在网络断连时全量复制的风险”,这种情况就是因为repl_backlog被覆盖写了,导致从库开始全量复制。不过这句的确不明显,不容易让大家注意,都是我的错。。。

    2020-08-17
    1
  • Geek_325aee
    老师我有个问题,我看到源码slave psync过程中,有slave共用rdb的情形,如下:
    (1)slave1发送psync,需要fullsync,master回复给slave1此时的master_repl_offset记为n
    (2)之后master开始接收写命令,增加master_repl_offset的值记为n+1,并将写命令写入到slave1的replication_buffer中
    (3)此时slave2来psync,master回复给slave1此时的master_repl_offset的值,即n+1;之后master发现正在为slave1生成rdb,那么为slave2复用这个rdb,再将slave1的replication_buffer中的内容复制给slave2;
    (4)当rdb生成完成后,将rdb发送给两个slave,并将缓冲区的命令集合发送出去。但是此时slave2的初始master_repl_offset值比slave1的多了1。此时slave2的这个repl_offset值就是错误的,实际上应该是从n开始累加。

    不知道我这里漏掉了什么步骤,或者理解错误?求老师解答。。

    我看的redis源码版本是3.0
    2020-08-25
收起评论
44
返回
顶部