高可用架构(上)

Posted 编号94530

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了高可用架构(上)相关的知识,希望对你有一定的参考价值。

1. 背景

在学习完各种高性能发实现方案后,就需要对三大复杂度一直的高可用进行开刀了,在高可用方面主要有哪些东西是我们需要考虑的呢?接下来将从三个方面逐一分析。

2. 理论

在设计高可用架构理论方面,我们主要有2个方向选择,分别是CAP理论和BASE理论,那什么是CAP,什么是BASE呢? 这个还是要好好分析一下。

2.1 CAP

  • C(Consistence):一致性
  • A(Availability):可用性
  • P(Partition Tolerance):分区容错性

一致性:指的是从所有节点获取的数据都是最新的(最新,那就是每个节点数据都是最新的数据,相同的)。

可用性:非故障节点在合理时间内返回合理响应。这个主要是为了排除一些非正常响应,如:超时,或者错误的结果

分区容错性:在发生网络异常时,系统能够继续保持任务运行

CAP理论有三个,但是在分布式系统中来说,只能选择其中两个。多系统网络中,我们无法保证网络100%正常,所以必须要选择P,保持系统继续运行,然后才是在C、A之间做取舍。如果选择CP, 那就是需要保证数据的一致,当无法保证数据一致时,就要对异常节点剔除,就无法保证系统可用性。当选择AP,当网络波动时,数据无法同步,无法保持最新数据,但系统可以访问。

通过上面的描述,有没有发现一个问题?这些理论都是针对数据来说的,当CP时,数据保证了一致,当AP时,数据不一致。我们有一个误区,认为系统设计一定要选AP,或者CP。其实这样是不正确的。因为在同一个系统中,可能部分数据需要保证AP,有一部分数据需要保证CP,例如:关于金额的数据则需要保证AP,但是用户相关昵称、简介可以使用AP。

所以,在系统正常运行的时候,是不存在选AP,还是CP的,我们应该同时关注CA。CAP的理论的前提是发生了网络分区,但是,当网络正常时,我们没有必要放弃A或C,我们应该同时满足。

2.2 BASE

  • B(Basically Available):基本可用
  • S( Soft State):软状态
  • E(Eventual Consistency):最终一致性

基本可用:分布式系统发生故障的时候,保证系统能够基本运行,允许损失部分可用性

软状态:过渡期,数据处于某中非最终状态。可以理解为:数据不一致

最终一致性:系统中的数据经过一段时间后,最终达到一致的状态(非实时一致)

BASE理论是对CAP理论的一种补充,在CAP中,C大多数指的情况是强一致性,在同一时刻,从所有节点获取的数据是相同的。而在BASE中,则通过软状态,和最终一致性来保证系统可用,而非在同一刻数据相同,而是通过一段时间后,所有节点数据相同。或者说,当系统发生分区故障时,数据不一致也可以使用,而最后通过通过,达到所有节点数据一致。

3. 接口层面

当在理论方面选择完可用性后,我们就需要在接口层面来考虑系统的可用性了。不然,一个接口调用,就搞挂系统,这样可就丢人啦。

通常,我们从接口层面考虑可用性主要分为4个方面,相信大家也是耳熟能详。分别是:熔断,限流,降级,排队。接下来就从这4个方面介绍。

3.1 熔断

熔断,这就和我们生活中的保险丝很像,当功率过大的时候,保险丝就会断掉,防止功率过大,引起火灾。我们在进行接口设计时,也需要考虑熔断,当系统接口调用失败,达到一定失败率或压力时,应该熔断系统。这里的熔断,不是指挂掉接口,而是快速响应。我们通过自定义响应内容,快速返回结果,响应客户端。熔断的核心理念也就是快速响应,保证系统可用。

3.2 限流

限流。这个就像我们周五进地铁,由于人多,防止地铁里的人员发生踩踏,拥挤事件,就在地铁口弄几个架子,让人慢慢排队,减小入口流量,保证地铁里的人流能够正常运行。限流和地铁这个没有大的区别,防止系统应对过大的流量,压垮系统,则通过闸口,控制进入系统的流量,这样可以使得系统在一个合理的流量内运行,保证了系统的正常运行。我们通过这样可以看得出来:限流是通过外部方式,来解决系统可用性。

3.3 降级

降级,那就是在流量高峰期间,关闭或减少系统其他功能,保证系统的核心功能可用。举个栗子:那就是淘宝双11的时候了,只能下单,而不能就行查单/或者只能查询最近几天的单。为什么呢?因为用户下单后可能进行大量的查单操作,占用大量系统资源,那就会影响下单,影响业务收入,这样就得不偿失。通过关闭查单,保证下单可用,这样就保证了核心系统的可用。

3.4 排队

排队,顾名思义,就是排队。就像网红奶茶店,大家都挤着去买奶茶,人员忙不过来,那咋办? 那大家就排队呗,在这等着,然后等到你的时候,在给你响应。在系统中,我们可以通过暂缓用户请求,排在队列中,让用户等待,限制处理量,等处理后在给用户响应。大家应该也有所发现,排队和限流还是蛮像的,限流是直接拒绝,而排队,是让用户等待。

4. 存储

从理论,到接口,那么接下来就是存储方面的高可用。在互联网中,大量的用户,大量的数据,带来的极多挑战,那么,我们到底有什么方案可以保证存储高可用呢?

存储高可用的本质都是通过将数据复制到多个存储设备,通过数据冗余的方式来实现高可用。其主要的复杂性体现在:数据同步延时和数据复制中断带来的数据不一致问题。所以我们也主要从四个方面考虑问题。1、数据如何复制,2、各个节点的职责,3、如果应对复制延迟,4、如果应对数据复制中断。

4.1 切换方式

常见的分布式方案有;主从,主备,主主

4.1.1 主备

主备,从字面意思理解,就是一个主节点,一个备机。 主节点用来处理所有的操作。备机从主节点备份数据,但是不对外提供服务。这种方式就是简单,切换主,备客户端无感知。缺点就是:备机仅仅用来备份,有些浪费。

4.1.2 主从

主从,从字面理解就是一个主人,一个随从。随从和备机还是有区别的,随从需要干活,备份不需要。主从和主备相似,只是从机需要提供查询服务。这中方式弥补了主备方式备机浪费的缺点,但也带来了新的问题,主从复制延迟问题,客户端需要根据情况切换到主机或备机。

4.1.3 主主

主主,顾名思义,就是两个节点都是主节点。双主带来的好处就是任何一个节点都可以进行读写操作,但缺点也显而易见。双主节点需要对对方的数据进行同步,这样就带来了同步延时的问题,同时,在同步的时候还会带来数据重复的问题。如:在A服务注册了手机号为F的用户,在B服务业注册了手机号为的用户,在合并时如何处理的。所以,在未考虑复杂性的时候,主主更适用于数据具有可重复性,可丢失的场景。

4.2 双机切换

我们从主备和主从的方案中发现,当主节点挂掉后,就无法在对外提供服务。这样就会导致服务宕机,那么我们就要采取一个合适的方案,来进行新的主节点的选取,那么就涉及到了双击切换

要设计切换方案,我们就要从这几个方面考虑:

4.2.1 主备间状态判断

主要包括:1、状态传递的渠道,也就是通过什么样的方式来传递内容。 2、 状态检测的内容:主要是通过什么东西来判断主节点是否挂掉,如:断电,进程死亡?

4.2.2 切换的决策

切换决策主要包含几个方面:1、什么时候切换,2、如何切换,3、切换的方式如何?

4.2.3 数据冲突问题

我们在切换过程中,可能主备/主从之间数据还未完全同步,如何保证切换后数据一致,这个就有点类似上面的主主方案了。

5. 总结

以上分享的是高可用架构理论,接口,存储方面的理论知识,在设计高可用的时候还是有许多要考虑的。如果有什么问题,欢迎指正,讨论

以上是关于高可用架构(上)的主要内容,如果未能解决你的问题,请参考以下文章

架构高可用高并发系统的设计原则

携程数据库高可用架构实践

架构师眼中的高可用架构设计之道

做了两年java,这些高性能高可用高并发的技术架构你都知道吗?

做了两年java,这些高性能高可用高并发的技术架构你都知道吗?

分布式架构高可用架构篇_04_Keepalived+Nginx实现高可用Web负载均衡