分布式系统之高可用方案
高可用方案初探
- 高可用方案
- CAP
- 计算高可用
-
- 对称式高可用
- 非对称式高可用
- 存储高可用
-
- 架构模式
-
- 双机热备
-
- 主备
- 主从
- 双主
- 集群和数据分区
-
- 集群模式
- 数据分区
- 异地多活
高可用方案
单点系统可能会由于断电，宕机等情况，使得系统不可用，在行业竞争激烈的情况下，系统的可用性会影响公司获客能力及口碑。
高可用分为计算高可用和存储高可用。
CAP
CAP分布式理论，C：一致性，A：可用性，P：分区容错性。
C：站在用户角度看，读操作能够看到最后一次写操作的结果。
A：系统总是能够在合理的时间内返回合理的结果（不包括超时，错误）
P：发生网络分区，系统依然可用。
根据cap理论，分布式系统只能在CP或AP之间进行选择，无法实现CA。特别强调CAP是忽略网络延迟的，也就是说对于CP来讲，只要不发生网络分区，各节点数据就是一致的。但由于网络天然的不可靠性，延迟是必然存在的，网络延迟不在CAP的讨论范围内。
CAP理论是站在数据的角度来考虑的，而不是站在系统的角度。一个系统存在各种各样的数据，如果站在整个系统的角度来决策是选择CP还是AP就会顾此失彼。比如，对于库存，余额等数据要求一致性，而对商品信息等对可用性要求高。因此可以针对业务或数据的特性来选择是CP还是AP。
计算高可用
计算高可用相比于存储高可用而言，其复杂度和难度降低不少。计算高可用方案的关键在于任务分发器的性能。任务分发器可以理解为类似于负载均衡。
对称式高可用
对称式高可用指集群中每个计算节点具有相同的地位，任务分发器平等的对待，每个节点都可以处理任意一个任务。架构图如下：
nodeX: 计算节点，每个节点地位同等。
上图任务分发器是独立的组件，不过从集群节点中选择一个当任务分发器也是可行，当出现故障时，从剩余可用的节点再选择一个作为任务分发器。如下图所示：
非对称式高可用
所谓非对称式高可用，就是集群中的计算节点角色不同，常见的有master-slave模式，leader-follower模式。
和对称式高可用架构看上去很相似，图中红色的线代表低优先级获其他属性的任务，黑色线代表高优先级获其他更优属性的任务。master节点通常拥有更高的配置，更强大的计算能力。
存储高可用
存储高可用的核心就是数据冗余，那么就必然存在数据备份或复制。
架构模式
常用的架构模式有以下几种
双机热备
双机顾名思义就是两个节点，具体设计方案有：主备，主从，双主，双主又分为：主动-主动模式 和 主动-被动模式。下面一一进行介绍。
主备
主从
主备模式是备节点只作为备份，不提供读写服务，而主从模式，从节点提供读服务，但不提供写。架构如下：
双主
双主模式有主动-主动模式，指两个节点都提供读写服务，且互为主备，因此模式一般并不能带来写性能的提升，反而会降低写性能，而且业务上和数据上还会出现各种各样的问题，一般都不推荐此模式，因此这里不过多介绍。下面介绍一下双主之主动-被动模式。
主动-被动模式的特点是：互为主备，主节点提供读写服务，被动节点仅提供读服务。架构如下：
此模式看起来和主从模式比较像，实际上这种模式和主从模式性能上来讲是一致的（配置相同的话）。但此模式有另外一个有点，就是当要进行一个比较耗时的操作时，能够减少对应用的影响。
如果要在一张大表上添加一个索引，为了不影响应用的写操作性能，我们可以这样做：
- 关闭主（被动）到 主（主动）的复制通道
- 在主（被动）节点上执行添加索引操作
- 切换它们的角色，也就是被动变主动，主动变被动
- 重新打开原被动节点到主动节点的复制通道。
集群和数据分区
集群模式在这里是指一主多从，一主多备模式。
一主多从虽然可以扩展读性能，但写性能可能会被降低，因为主节点挂多个从节点，会占用主节点的资源。
数据分区模式，类似于redis cluster 或者一致性Hash环方式。
集群模式
主备和这个类似，区别是备节点不提供读写服务。除了这种架构，还存在树形的架构，这里不再提供示意图（自行脑补）。
数据分区
数据分区的特点是集群中每个节点只存储部分数据，而不是全量数据。数据会根据某些字段来划分其应当落在哪个节点上。这种模式除了既能够扩展读性能，也能够扩展写性能，而且当某个节点发生故障时，只是部分数据或者部分业务暂时受到影响。除此之外，每个分区同样也可以采用主备，主从等手段冗余数据，提高可用性。
数据分区模式，使得数据被割裂存储，虽然提高了存储系统整体的可用性，但对于全量数据或跨分区数据的查询操作（如分页）却不友好。解决此类问题可以通过构建搜索引擎（如Elasticsearch等）来提高这种类型查询的失效和性能问题。
还有一种场景：订单系统中订单，如果按照订单ID来分区，那么同一用户的订单会散落在不同的分区里，按照订单ID来查询数据是没有问题，但对于商家来说，商家想要查询某个商家ID的所有订单，因为没有按照商家进行分区，那么这种查询就会扫描所有分区，查询性能低效。解决此种问题，可以通过异构索引表的方式，具体方式就是多维度分区，同一个订单既按照订单ID分区，也按照商家ID分区。按照商家ID查询时，只会查询一个库，能够得到对用的订单ID,然后就可以使用订单ID进行in操作，可以避免全局扫描，当然在创建以商家ID为分区的数据时，也可以拿空间换时间，就是冗余订单信息，这样就只需要一次查询。
下图如下为数据分区架构-数据查询：
异地多活
更高的可用性，意味着更高的成本，更高的复杂度。对于大公司而言，往往还会进行异地多活的架构。
异地多活常见方式有：
- 同城跨区
- 跨城
- 跨国
- 跨洲
异地多活同样适用于计算高可用，计算高可用的异地多活只需要简单的搭建一套完整的系统即可。高可用异地多活的复杂度及成本是及其高昂的。