25 | 高可用存储架构:双机架构

2018-06-23 李运华
《从 0 开始学架构》
课程介绍


讲述:黄洲君

时长:大小7.10M


存储高可用方案的本质都是通过将数据复制到多个存储设备,通过数据冗余的方式来实现高可用,其复杂性主要体现在如何应对复制延迟和中断导致的数据不一致问题。因此,对任何一个高可用存储方案,我们需要从以下几个方面去进行思考和分析:
数据如何复制?
各个节点的职责是什么?
如何应对复制延迟?
如何应对复制中断?
常见的高可用存储架构有主备、主从、主主、集群、分区,每一种又可以根据业务的需求进行一些特殊的定制化功能,由此衍生出更多的变种。由于不同业务的定制功能难以通用化,今天我将针对业界通用的方案,来分析常见的双机高可用架构:主备、主从、主备 / 主从切换和主主。

主备复制

主备复制是最常见也是最简单的一种存储高可用方案,几乎所有的存储系统都提供了主备复制的功能,例如 MySQL、Redis、MongoDB 等。
1. 基本实现

展开全文
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。

精选留言

  • 空档滑行
    2018-06-23
    政府信息网站使用主备或者主从架构就可以了。信息都是人工录入,可以补录。数据本来对实时性要求不高,所以出了故障人工修复也来得及。所以主备就够了,如果为了照顾形象可以用主从,保证主机故障后仍然可以查,不能新发

    作者回复: 分析正确

    
    83
  • 姜戈
    2018-12-13
    网上搜索了一下:
    在软件系统的高可靠性(也称为可用性,英文描述为HA,High Available)里有个衡量其可靠性的标准——X个9,这个X是代表数字3~5。X个9表示在软件系统1年时间的使用过程中,系统可以正常使用时间与总时间(1年)之比,我们通过下面的计算来感受下X个9在不同级别的可靠性差异。

    3个9:(1-99.9%)*365*24=8.76小时,表示该软件系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
    4个9:(1-99.99%)*365*24=0.876小时=52.6分钟,表示该软件系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
    5个9:(1-99.999%)*365*24*60=5.26分钟,表示该软件系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
    那么X个9里的X只代表数字3~5,为什么没有1~2,也没有大于6的呢?我们接着往下计算:

    1个9:(1-90%)*365=36.5天
    2个9:(1-99%)*365=3.65天
    6个9:(1-99.9999%)*365*24*60*60=31秒
    可以看到1个9和、2个9分别表示一年时间内业务可能中断的时间是36.5天、3.65天,这种级别的可靠性或许还不配使用“可靠性”这个词;而6个9则表示一年内业务中断时间最多是31秒,那么这个级别的可靠性并非实现不了,而是要做到从5个9》6个9的可靠性提升的话,后者需要付出比前者几倍的成本,所以在企业里大家都只谈(3~5)个9。
    展开
    共 1 条评论
    38
  • 文竹
    2018-08-22
    政府信息公开网站的特点:
    1、用户量和QPS不会很大
    2、其次读/写都非常少,读相较于写多
    3、可忍受一定时间范围的不可用

    主主架构因其固有的双向复杂性,很少在实际中使用;再加上此场景并不适合用主主架,故排除使用它。

    根据第3个特点就可以排除使用双机互换架构。

    对于主备架构来说,主机正常时,备机不提供读写服务,比较浪费。

    综合来看,选择主从的存储架构。

    展开

    作者回复: 正确

    共 2 条评论
    18
  • 南友力max先森🌈
    2018-07-16
    单机就可以了,搞那么复杂

    作者回复: 单机可靠性只有2个9

    共 4 条评论
    11
  • 今夕是何年
    2018-06-23
    政府信息网站使用主从就行了,因为读的请求多,写的请求少。
    网站挂掉影响也不大,所以可以不用主从切换。
    
    9
  • 无聊夫斯基
    2018-08-31
    复制延迟和复制中断的数据不一致的解决方案好像没看到

    作者回复: 没有解决方案,只能规避和兼容

    
    7
  • Geek_88604f
    2019-09-13
    中介式相对于互联式来说有如下优势:一是状态决策更加准确。举个例子,在互联模式下如果连接中断则无法判断对方的状态,切也不是,不切也不是;而在中介模式下一方连接中断(无论是主机和中介中断还是备机与中介中断)仍然能够做出决策,就连接来说多了一条冗余判断的方式,毕竟两个连接同时中断的概率更小。如果用上节课介绍的FMEA方法逐个分析的话,会发现中介模式可以解决更多的故障模式。二是将状态决策的逻辑解耦,主备只需要上报状态不需要承担状态的决策,状态决策的逻辑全部由中介来负责,并且可以灵活定制决策逻辑。
            模拟式相对于互联式来说走一下不足:一是提供的判决依据不够;二是信息不正确,模拟读写操作可能已经完成了但是由于网络拥塞的原因不能及时返回。而互联式有独立的状态通道可以保证传输优先级。
            一个政府信息公开网站的信息存储系统,从场景上来看分为管理员发布信息和人们查看信息,这些信息基本上都是严肃的官方的非临时信息,因此主主模式不合适;同时这些信息基本上都是读多写少,平时更新频率不高,因此考虑主备或主从。从业务要求上看整体的TPS和实验要求不高,因此考虑主备即可,同时即使主集群宕机了能够在半天内恢复问题不大(毕竟这些网站不是经常使用的),这也就不需要做状态检测了。因此综合来说选择主备无状态检测的方案。
    展开

    作者回复: 分析到位

    
    5
  • zcode
    2019-07-02
    老师,主备负责方案,主挂了的时候,系统就会有一段时间不可用了吧?怎么样人工把备机改成主机呢,应用是不是还要修改数据ip的配置呢,具体怎么操作能不能详细说一下?

    作者回复: 可以改数据库的ip,也可以改应用系统上配置的数据库ip

    共 2 条评论
    4
  • 忠厚
    2018-06-27
    数据持久化信息我可能会选择主备模式,备机主做数据备份不提供读写操作。

    添加一个redis缓存全量信息数据,做一个哨兵模式,实现故障切换,提高网站的可用性

    应用上再使用个Ehcache堆外缓存,主要把热点信息放到应用里提升性能.

    这样做相对主从模式,读并发压力过大时,扩容更容易
    展开

    作者回复: 缓存设计得比较复杂了,我认为ehcache没有必要

    
    4
  • 孙振超
    2018-08-06
    双机切换架构里面的中介模式是由db连接到中介,而后中介告诉它应该是主还是备,这种模式下要求db能够根据中介的返回结果实时的修改自己的模式,同时当客户端请求类型和当前模式不匹配时返回调用失败。对于mongo db原生支持还是可以,如果是原生不支持的db,是不是改为客户端直接链接中介,根据请求类型获取对应的db ip可用性更好些,如同zookeeper?又或者mongo db采用客户端直接链接中介是否也可以?因为中介模式本身对中介的高可用要求也比较高。

    作者回复: 客户端直连中介,需要中介理解存储系统的协议,这个做不到通用,MySQL Router可以实现你说的功能,但只适应MySQL,如果你基于zk做一套中介,可以支撑MySQL, mongodb等

    
    2
  • 王虹凯
    2018-07-06
    关于主主互相复制相关的有没有进一步讲解。

    作者回复: 没太多可讲的呢,主要是设计数据防冲突策略和冲突解决方案,例如A机房生成奇数数据,B机房生成偶数数据

    
    2
  • 陳先森
    2019-05-28
    你好,老师这些存储,如果我要做自动切换,比如:互联式,中介式,模拟式。大致哪类存储比较适合哪种模式,又类如哪种存储用互联式通过哪种中间件去实现。因为我是做运维的可能就比较关注这个东西

    作者回复: 看需求而定,你可以研究一下HBase,ES,Redis等集群的实现

    
    1
  • 刘鹏
    2018-11-04
    老师我是这么理解的,数据库主从实现读写分离保证了数据库的高性能,但是没有保证数据库的高可用,主机崩掉后,数据库不在提供写服务,而从库只能进行读操作,拒绝写服务。所以需要在主从之间加入主从切换的规则,当主机崩掉后,从机可以进行自主升为主机,从而保证高可用,这种机制就可以保证数据库的高性能和高可用,但是感觉这种复杂度太高了,真的会使用这种架构吗?

    作者回复: 用得很多啊😄

    
    1
  • 大熊
    2018-10-29
    老师,你好。数据冲突解决,下文好像没怎么讲具体的解决方案,能否帮忙讲解下呢,谢谢

    作者回复: 目前出现数据冲突都是靠人工修复,或者覆盖一些数据,或者直接丢失一些数据,异地多活的章节会讲

    
    1
  • listen to you
    2018-07-27
    请问主从数据一致性如何保证?如何补救?

    作者回复: 没法保证实时一致性,最终一致性依赖存储系统的同步就可以了

    
    1
  • 100kg
    2018-07-10
    随着用户量的增大,肯定要上多主多备的,这样的情况对于“库存”字段该怎么处理呢?

    作者回复: 考虑后面介绍的数据分散集群,集群中每个机器存储一部分库存数据

    
    1
  • 100kg
    2018-07-07
    那老师,如果采用主主的方式做mysql集群,对于库存字段该怎么处理呢? 乐观锁管用吗?

    作者回复: 库存别用主主架构

    
    1
  • 来
    2018-07-05
    楼主你好,我看你文章中也提到了主从复制延迟和复制中断,我想问下当你们系统出现复制延迟后你们采用的处理方案是什么,还有就是复制中断(可能是网络闪断,也可能是从机宕掉,从机再次启动)后,当主从再次连接后,主机是如何准确的把未同步的数据同步到这台从机上的呢,因为我一个主机可能有多个从机,只是其中一个从机有问题,麻烦楼主帮忙解答下,谢谢

    作者回复: 1. 复制延迟一般只能等
    2. 复制中断后的恢复,需要有机制判断复制进度和位置,参考mysql的binlog复制

    
    1
  • 成功
    2018-06-27
    1)这种政府公开信息系统,TPS应该很低,因为政务信息一般按天发布。QPS相对比高,阅读政务的人群比较多,而且被转载可能性大。
    2)技术选型zk(3台低配设备)+MysqL主从集群(2台高配设备)+Web服务器(1台中配设备)
    3)Zk对MysqL客户端做高可用(3个节点)
    4)MysqL集群用互连式主从设计,主节点负责写入和读取,从节点负责读取。主从之间同步数据和状态,同步数据和状态拉一根专线即可。

    作者回复: 这个设计还是太复杂了,zk完全可以不用

    
    1
  • 叶伟
    2018-06-24
    政府网站特殊性,更多属于公告通知类的内容,使用主备即可,读的高频率可以用缓存、cdn等其他方式实现,遇到突发事件访问量过大时,避免让压力直接落在db上
    
    1