高可用架构（上）

Posted 2022-12-04 编号94530

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. 总结

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