美文网首页微服务架构和实践
《Designing Data-Intensive Applic

《Designing Data-Intensive Applic

作者: 赤子心_d709 | 来源:发表于2018-01-08 09:52 被阅读84次

    1.前言

    前面讲了单leader模型,本节讲解多leader备份

    2.多leader备份

    之前讲的单leader有一个大的缺陷:
    由于只有一个leader,client和leader连不上,就不能写了

    那么一个拓展就是单leader变成多leader,每个leader都允许写,备份过程基本不变,如下:

    接收写请求的节点把数据发送给其他所有节点。
    此时,每个leader都会作为其他leader的follower角色
    

    2.1 何时用多leader模型

    根据数据中心的个数决定
    如果只有一个,那么就是单leader(此时多leader太复杂了且无必要)
    如果有多个,就用多leader

    多leader模式下,每个数据中心都能有一个leader
    在每个数据中心内部,就是常规的单leader模型
    在数据中心之间,则是每个leader和其他leader互相备份。
    

    如下图


    多数据中心的多leader备份

    注意数据中心之间,leader间进行冲突解决以及备份

    在多数据中心的情况下比较单leader和多leader:

    1.单leader配置接收所有写,延迟高,违背了单多数据中心的意愿。而多leader则能在最近的leader进行写,并且异步备份。
    2.单leader挂了重选的leader可能在另外一个数据中心。而多leader模型中每个数据中心能够相对独立工作(只有leader间互相备份)
    3.单leader对网络问题更敏感,多leader不会
    

    但是多leader有一个缺点:
    一个数据同时在两个不同的数据中心修改,需要解决冲突
    这个问题很复杂但又很常见,比如
    同一个app在不同客户端上离线设置,重新联网后需要同步数据

    2.2 处理写冲突

    上面讲解的冲突触发的场景可以如下图所示


    各leader同时修改数据

    2.2.1 冲突检测:同步还是异步

    同步异步冲突检测都有各自问题

    同步检测的话,损失了多leader允许同时写的优势。好处是能让用户知道发生了冲突及时修改
    异步检测的话,会有延迟,也不能再让用户改。好处是快。
    

    2.2.2 避免冲突

    最简单的办法是避免冲突:对每个特定的记录写的请求会通通给同一个leader
    比如把每个user分配到特定的 home数据中心。
    当然,还得考虑这个数据中心leader挂掉的情况

    2.2.3 收敛到一致性状态

    单leader能够使得所有写按顺序执行
    但是在多leader的配置中,不保证这个顺序,但是要保证最后一个最终的结果应用到所有的备份中去,有以下方法:

    1.给写请求分配ID,谁大以谁为准
    2.给节点分配ID,谁大以谁为准
    3.把结果合并起来如B/C
    4.记录结果,后面写业务代码去解决
    

    2.2.4 冲突解决的策略

    很多多leader的工具允许自己写冲突解决的方案,包括写的执行以及读的执行两个方面

    写时
      检测到冲突了之后,调用conflict handler,能执行自己写的PERL脚本
    读时
      检测到冲突后,所有冲突的数据都会被记录。下次这个数据被读取时,多个版本的数据都会返回给应用,应用自己决定如何处理
    

    2.2.5 什么是冲突

    有些冲突明显,修改同一条记录同一个字段。
    有些则不明显,比如一个预订系统,两人同时预定一个位置。
    (这里不是很理解这一节是干吗的,这个例子只是db换一个方式冲突,而且也能用2.2.4的方案解决啊)

    2.3 多leader备份的拓扑关系

    需要一个拓扑关系来表识写请求在节点之间的传递,有下面几种


    三种多leader备份模型

    最常见的是all-to-all这种,所有leader之间互相通信。
    MySQL则默认用circular模型。是一个环状结构。
    另外星形结构可以看做是树形结构,由一个root节点向所有其他节点通信。

    在环形和星形中间,一个写可能要经过多次传输到达其他节点(星形的话可能是叶子-根-叶子这样传输)
    为了避免传递时出现死循环,每个节点都会有一个唯一id。每个传递的消息会记录传递路径的节点的id。

    环形和星形的问题是如果一个节点挂了,整个通信结构都可能受到影响,往往需要人为的修复。

    另一方面,all-to-all的结构,受到网络通信的影响,可能造成备份的数据会出现 改动顺序颠倒的情况(之前提到的前缀一致性问题),如下图


    破坏了前缀一致性,造成了错误顺序

    为了保证顺序性,称为“version vectors”的技术被提出,后面再讲。

    3.思考

    星形网络

    换一个角度看就是一棵树

    多leader的主要问题

    就是写会有冲突,要尽量避免冲突,收束到一致性,再检测冲突,解决冲突
    但是感觉解决冲突的成就还是比较poor的。

    4.问题

    解决冲突造成的倾向性问题

    2.2.3里面说比如给节点分配ID,谁大以谁为准,这也是有倾向性的
    而2.2.5中提出的 “什么是冲突”感觉完全可以解决掉,不知道书中这样编排的目的是啥

    5.总结

    这部分主要讲解:
    多leader适用的场景
    然后面对的主要问题是写冲突,如何检测,避免,解决冲突
    最后讲解了多leader中,各个leader互相备份的三种模型

    相关文章

      网友评论

        本文标题:《Designing Data-Intensive Applic

        本文链接:https://www.haomeiwen.com/subject/jxssnxtx.html