架构系列-高可用架构，为什么要做高可用架构

一、CAP理论

    准确的定义是：在一个分布式系统中（互相连接并共享数据的节点的集合）中，涉及到读写操作时，只能保证一致性C（客户端读保证得到最新的写结果）、可用性A（返回noerror notimeout）、分区容错性P（出现分区后系统可以继续履职）三个中的两个，必须牺牲另一个。在实际中，无论如何都要满足P，因为如果没有P，在网络故障时，要保重C就必须停止写入，但A要求返回noerror和notimeout，所以A也不满足。网络分区错误类似脑裂、数据同步中断，最坏的情况是主从连接断开，各自成为了独立个体。

二、CAP细节：

    1、CAP：

        （1）CAP关注的是数据，而不是整个系统。比如账号信息是CP，而用户资料是AP。

        （2）CAP是忽略网络延迟的。数据复制是有延迟的，即时在内网也有几毫秒，对于金钱和秒杀类的场景，一致性C是无法完美实现的。但并不是说这类业务不能做分布式，可以把同一用户、同一商品放在同一个机器，同一用户做不了分布式，但是整个业务是个做的，比如根据uid分布在不同机器。

        （3）正常情况下，是可以同时满足CAP的。P强调的是网络分区错误时，CA二选一。但是在网络正常情况下，CAP就可以同时满足。分区故障时，选择CP的，节点1可以注册，节点2不可以注册，可以节点1打日志，恢复注册后同步到节点2，CA同时存在。选择AP的，节点1和节点2是用户两次不同的修改，恢复后可以根据时间优先来进行覆盖，最终达到同时满足AP。

    2、ACID：原子性、一致性（食物开始前和结束后，数据库完整性没有被破会）、隔离性（隔离级别）、持久性（事务提交后就是永久的哪怕发生故障）、和CAP中的AC完全不是相同含义，ACID的C是数据库完整性，A是原子性，指事务要么都完成或都回滚；ACD的C是节点数据一致性，A是读写可用性。

    3、BASE：BA（基本可用）和S（软状态）和E（最终一致性）。是对CAP理论的AP的补充。AP分区时放弃的是网络分区这段时间的一致性，但恢复后最终会一致。

        （1）基本可用：允许损失部分可用性，保证核心可用。如可以不注册，但是要保证登陆，否则影响更大。

        （2）软状态：允许出现中间状态，不影响整体可用性。这种中间状态就是CAP理论的数据不一致。

        （3）最终一致性：数据同步一定是有延迟的，只要保证最终一致性即可。如注册后不超过一分钟可以在各个节点登陆。明星发微博后可以三十分钟内同步到所有用户  

    

三、FMEA方法论：故障模式与影响分析

四、高可用存储-双机架构

    1、主备：简单，但是浪费资源，手动扶正。

    2、主从：主挂后可以继续读，但客户端调用时需要知道谁主谁从。故障后需要人工扶正。

    3、双机切换：在主备和主从上加入了切换功能，数据库自己做还是加入第三方、状态如何传递、如何判定故障、自动还是半自动、是否切换角色。

    4、互链式：主备之间除了数据同步，还要状态同步，可以是网络连接和有线连接等VIP自动飘移。但是这个链接管理是难点，可能出现两个都是主。

    5、中介式：引入第三方，弥补互链式缺点。

    6、模拟式：备机当作客户端访问主机。

    7、主主：客户端任写其一，主主互相同步，不做状态和切换。缺点是主键和数据冲突，如用户id商品库存等无法这么做。

五、高可用存储-集群和分区架构

    1、集群：

        （1）、一主多从多备，多备机都要检测主机状态，通常引入第三方如zookeeper，复杂度变高。

        （2）、多主，数据分散写在不同集群，要考虑均衡性、容错性、伸缩性。

    2、分区：分散在地域机房及以上的级别。如果备份要提供服务，则距离不可太远，否则网络不可靠。

        （1）集中式：北京分区上海分区都备份在西安机房。

        （2）互备式：北京备份在上海，上海备份在广州，广州备份在北京

        （3）独立式：各个分区有各自独立的备份机房。

六、高可用计算

    分为主备。主从。集群。集群分为对称和非对称。对称是执行相同任务，非对称则需要区分任务。非对称集群需要处理分发策略和主机选举策略。计算高可用就是通过冗余来解决单点问题，但存储高可用还有数据一致性、对机器之间同步和状态心跳等问题，更为复杂。

七、业务高可用：异地多活

    1、多活复杂度较高，规模以下企业多备即可

    2、方案：

        （1）同城异区主要应对机房故障。

        （2）异地（北京广州）多活复杂度很大，网络延迟，光缆中断等原因导致金钱等敏感业务是做不了多活的。多活为了高可用，但是数据不一致肯定不可用，这是矛盾的。

        （3）跨国多活：通常只有只读业务，和不同地区为不同客户数据不互通。复杂度不高。

八、异地多活技巧

    同城跨区可以将两机房连起来就像内网一样。跨国面向不同用户提供不同服务复杂度不高。这里主要讨论跨城。复杂度来源主要还是网络延迟和机房异常

    1、保证核心业务和高收入业务：比如登陆，核心业务方案简单。而注册是主要任务，同时异地多活复杂度极高。高收入业务会影响财报和广告主口碑等

    2、最终一致性：同步完成之前，B可以路由回A请求。

    3、对手段同步：mysql只有单线程，redis需要全量rdb文件重新做。同步方式有：异步队列、二次读区、存储系统同步、回源读、重新生成等方式。

    4、只保证大部分用户：异地多活方案无法做到100%。

九、接口级故障：限流

    核心思想是保障核心业务和大部分用户。

1. 降级：指服务内部处理方案，如关闭注册、看帖不能发帖、应用日志接口。有内部提供URL和独立模块实现的方式。

2. 熔断：指依赖的其他服务异常。实现的机制是要对对方服务采样统计，设计阈值。

3. 限流：基于流量限流如1分钟超过一万就丢弃；基于资源限流如负载高低和队列容量等。

4. 排队：借助队列系统。一号店秒杀方案：排队模块，一个商品一个队列；调度模块，业务服务空闲时出队一个交给业务服务处理；业务模块，真正处理业务的。 

本文地址：https://blog.csdn.net/bcsj1199/article/details/107446796