分布式系统之高可用方案

高可用方案

单点系统可能会由于断电,宕机等情况,使得系统不可用,在行业竞争激烈的情况下,系统的可用性会影响公司获客能力及口碑。

高可用分为计算高可用和存储高可用。

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节点通常拥有更高的配置,更强大的计算能力。

存储高可用

存储高可用的核心就是数据冗余,那么就必然存在数据备份或复制。

架构模式

常用的架构模式有以下几种

双机热备

双机顾名思义就是两个节点,具体设计方案有:主备,主从,双主,双主又分为:主动-主动模式 和 主动-被动模式。下面一一进行介绍。

主备

主备

主从

主备模式是备节点只作为备份,不提供读写服务,而主从模式,从节点提供读服务,但不提供写。架构如下:
主从

双主

双主模式有主动-主动模式,指两个节点都提供读写服务,且互为主备,因此模式一般并不能带来写性能的提升,反而会降低写性能,而且业务上和数据上还会出现各种各样的问题,一般都不推荐此模式,因此这里不过多介绍。下面介绍一下双主之主动-被动模式。

主动-被动模式的特点是:互为主备,主节点提供读写服务,被动节点仅提供读服务。架构如下:
主动被动

此模式看起来和主从模式比较像,实际上这种模式和主从模式性能上来讲是一致的(配置相同的话)。但此模式有另外一个有点,就是当要进行一个比较耗时的操作时,能够减少对应用的影响。

如果要在一张大表上添加一个索引,为了不影响应用的写操作性能,我们可以这样做:

  1. 关闭主(被动)到 主(主动)的复制通道
  2. 在主(被动)节点上执行添加索引操作
  3. 切换它们的角色,也就是被动变主动,主动变被动
  4. 重新打开原被动节点到主动节点的复制通道。

集群和数据分区

集群模式在这里是指一主多从,一主多备模式。
一主多从虽然可以扩展读性能,但写性能可能会被降低,因为主节点挂多个从节点,会占用主节点的资源。

数据分区模式,类似于redis cluster 或者一致性Hash环方式。

集群模式

一主多从

主备和这个类似,区别是备节点不提供读写服务。除了这种架构,还存在树形的架构,这里不再提供示意图(自行脑补)。

数据分区

数据分区的特点是集群中每个节点只存储部分数据,而不是全量数据。数据会根据某些字段来划分其应当落在哪个节点上。这种模式除了既能够扩展读性能,也能够扩展写性能,而且当某个节点发生故障时,只是部分数据或者部分业务暂时受到影响。除此之外,每个分区同样也可以采用主备,主从等手段冗余数据,提高可用性。
数据分区

数据分区模式,使得数据被割裂存储,虽然提高了存储系统整体的可用性,但对于全量数据或跨分区数据的查询操作(如分页)却不友好。解决此类问题可以通过构建搜索引擎(如Elasticsearch等)来提高这种类型查询的失效和性能问题。

还有一种场景:订单系统中订单,如果按照订单ID来分区,那么同一用户的订单会散落在不同的分区里,按照订单ID来查询数据是没有问题,但对于商家来说,商家想要查询某个商家ID的所有订单,因为没有按照商家进行分区,那么这种查询就会扫描所有分区,查询性能低效。解决此种问题,可以通过异构索引表的方式,具体方式就是多维度分区,同一个订单既按照订单ID分区,也按照商家ID分区。按照商家ID查询时,只会查询一个库,能够得到对用的订单ID,然后就可以使用订单ID进行in操作,可以避免全局扫描,当然在创建以商家ID为分区的数据时,也可以拿空间换时间,就是冗余订单信息,这样就只需要一次查询。

下图如下为数据分区架构-数据查询:
数据分区

异地多活

更高的可用性,意味着更高的成本,更高的复杂度。对于大公司而言,往往还会进行异地多活的架构。

异地多活常见方式有:

  • 同城跨区
  • 跨城
  • 跨国
  • 跨洲

异地多活同样适用于计算高可用,计算高可用的异地多活只需要简单的搭建一套完整的系统即可。高可用异地多活的复杂度及成本是及其高昂的。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值