高可用02:高可用系统设计之「架构高可用」


高可用系列目录


如何设计一个高可用系统

上一节我们已经介绍了什么是高可用以及高可用相关的一些概念,接下来我们分几个章节来介绍:如何设计一个高可用系统?

image-20220313160723990

大型系统的分层架构及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点。关闭服务或服务器宕机时产生的影响也不相同,高可用的解决方案也差异甚大。大致可以分为:

  • 高可用的架构 - 主要方式是:主备、主从、双主、集群、分区
  • 高可用的应用 - 主要手段是:负载均衡
  • 高可用的服务 - 主要手段是:分级管理、超时重试、异步调用、限流、降解、断路、幂等性设计
  • 高可用的数据 - 主要手段是:数据备份和失效转移

架构高可用

常见的机构模式有:双机(主备、主从、主主等)、集群、分区等。

(1)主备复制

主备复制是最常见也是最简单的一种存储高可用方案,几乎所有的存储系统都提供了主备复制的功能,例如 MySQL、Redis、MongoDB 等。主备模式中,两台服务不再是平等关系。主服务承担所有的读写请求,备服务只有在主服务不可用时才取而代之。主备服务之间虽然也存在两个方向的数据同步,但跟双主模式不同,它们不会同时发生。正常情况下只存在主向备同步数据。主不可用的时间段内,数据会写到备服务。当主恢复后,才需要由备向主同步数据。在此期间,会双写数据到主备节点,防止主同时再向备同步数据。主备架构比较容易实现,缺点是备服务在绝大部分时间是一种资源浪费。一般数据库系统在部署时会考虑主备架构。

主备复制要点:

  • 存在一主多备

  • 主机负责读&写,并定期复制数据给备机。

  • 一旦主机宕机,可以通过人工手段,将其中一个备节点作为主节点。

    image-20220313160803044

优点

  • 主备复制架构中,客户端可以不感知备机的存在。即使灾难恢复后,原来的备机被人工修改为主机后,对于客户端来说,只是认为主机的地址换了而已,无须知道是原来的备机升级为主机。
  • 主备复制架构中,主机和备机之间,只需要进行数据复制即可,无须进行状态判断和主备切换这类复杂的操作。

缺点

  • 主备复制架构中,故障后需要人工干预,无法自动恢复。

适用场景

综合主备复制架构的优缺点,内部的后台管理系统使用主备复制架构的情况会比较多,例如学生管理系统、员工管理系统、假期管理系统等,因为这类系统的数据变更频率低,即使在某些场景下丢失数据,也可以通过人工的方式补全。

(2)主从复制

主从复制和主备复制只有一字之差,“从”意思是“随从、仆从”,“备”的意思是备份。我们可以理解为仆从是要帮主人干活的,这里的干活就是承担“读”的操作。也就是说,主机负责读写操作,从机只负责读操作,不负责写操作。

主从模式其实不是主要解决高可用问题的,更多的是为了实现读写分离,来解决高并发问题。实际场景中通常不是一主一从,而是一主多从架构,因为大部分应用都是的读多写少。主节点处理写请求,从节点处理读请求。由于存在多从,读服务的可用性远高于写服务。另外,写服务会存在单点故障。这个问题可以通过集群动态选主来解决:当主节点不可用时,集群自动选出一台新的主节点。基于zookeeper,动态选主很容易实现。不过动态选主在MySQL集群架构中不会使用,原因是主从同步数据必须在部署时配置好,切换了主节点还是需要运维人工介入修改配置并重启服务。

image-20220313160959711

优缺点分析

主从复制与主备复制相比,优点有:

  • 主从复制在主机故障时,读操作相关的业务可以继续运行。

  • 主从复制架构的从机提供读操作,发挥了硬件的性能。

缺点有:

  • 主从复制架构中,客户端需要感知主从关系,并将不同的操作发给不同的机器进行处理,复杂度比主备复制要高。

  • 主从复制架构中,从机提供读业务,如果主从复制延迟比较大,业务会因为数据不一致出现问题。

  • 故障时需要人工干预.

综合主从复制的优缺点,一般情况下,写少读多的业务使用主从复制的存储架构比较多。例如,论坛、BBS、新闻网站这类业务,此类业务的读操作数量是写操作数量的 10 倍甚至 100 倍以上。

(3)双机切换

以上介绍的主备复制和主从复制都存在两个比较致命的问题,那就是并非100%高可用。主要体现在:

  • 主机故障后,无法进行写操作。
  • 如果主机无法恢复,需要人工指定新的主机角色。

双机切换就是为了解决这两个问题而产生的,包括主备切换和主从切换两种方案。简单来说,这两个方案就是在原有方案的基础上增加“切换”功能,即系统自动决定主机角色,并完成角色切换。

常见的主备切换架构有三种形式:互连式、中介式和模拟式。具体细节感兴趣可以参考这篇文章——高可用存储架构:双机架构

(4)双主模式

双主模式中,两台服务是平等关系,同时对外提供读写服务,客户端任选一台即可。双主模式是可用性最好的,但是这种架构的一致性处理比较困难,需要两台服务进行双向数据同步。一旦它们之间的通信断开,就形成了网络分区,这种分区会带来脑裂(brain-split)问题,并且系统对此无解,必须人工介入。所以在架构设计时极少选择双主模式。

image-20220313161033607

(5)数据集群

image-20220313161130766

主备、主从、主主架构本质上都有一个隐含的假设:主机能够存储所有数据,但主机本身的存储和处理能力肯定是有极限的。早在 2013 年,Facebook 就有 2500 亿张上传照片,当时这些照片的容量就已经达到了 250 PB 字节(250 × 1024TB),平均一天上传的图片有 3 亿 5000 万张。如此大量的数据,单台服务器肯定是无法存储和处理的,我们必须使用多台服务器来存储数据,这就是数据集群架构。

简单来说,集群就是多台机器组合在一起形成一个统一的系统,这里的“多台”,数量上至少是 3 台;相比而言,主备、主从都是 2 台机器。根据集群中机器承担的不同角色来划分,集群可以分为两类:数据集中集群、数据分散集群。

①数据集中集群

数据集中集群与主备、主从这类架构相似,我们也可以称数据集中集群为 1 主多备或者 1 主多从。无论是 1 主 1 从、1 主 1 备,还是 1 主多备、1 主多从,数据都只能往主机中写,而读操作可以参考主备、主从架构进行灵活多变。虽然架构上是类似的,但由于集群里面的服务器数量更多,导致复杂度整体更高一些,具体体现在:

  • 主机如何将数据复制给备机
  • 备机如何检测主机状态
  • 主机故障后,如何决定新的主机

②数据分散集群

数据分散集群指多个服务器组成一个集群,每台服务器都会负责存储一部分数据;同时,为了提升硬件利用率,每台服务器又会备份一部分数据。

数据分散集群的复杂点在于如何将数据分配到不同的服务器上,算法需要考虑这些设计点:

  • 均衡性

    算法需要保证服务器上的数据分区基本是均衡的,不能存在某台服务器上的分区数量是另外一台服务器的几倍的情况。

  • 容错性

    当出现部分服务器故障时,算法需要将原来分配给故障服务器的数据分区分配给其他服务器。

  • 可伸缩性

    当集群容量不够,扩充新的服务器后,算法能够自动将部分数据分区迁移到新服务器,并保证扩容后所有服务器的均衡性。

数据分散集群和数据集中集群的不同点在于,数据分散集群中的每台服务器都可以处理读写请求,因此不存在数据集中集群中负责写的主机那样的角色。但在数据分散集群中,必须有一个角色来负责执行数据分配算法,这个角色可以是独立的一台服务器【例如Hadoop的Namenode】,也可以是集群自己选举出的一台服务器【例如ElasticSearch的master node】。

如果是集群服务器选举出来一台机器承担数据分区分配的职责,则这台服务器一般也会叫作主机,但我们需要知道这里的“主机”和数据集中集群中的“主机”,其职责是有差异的。

③总结

数据集中集群架构中,客户端只能将数据写到主机;数据分散集群架构中,客户端可以向任意服务器中读写数据。正是因为这个关键的差异,决定了两种集群的应用场景不同。一般来说,数据集中集群适合数据量不大,集群机器数量不多的场景。例如,ZooKeeper 集群,一般推荐 5 台机器左右,数据量是单台服务器就能够支撑;而数据分散集群,由于其良好的可伸缩性,适合业务数据量巨大、集群机器数量庞大的业务场景。例如,Hadoop 集群、HBase 集群,大规模的集群可以达到上百台甚至上千台服务器。

【延伸阅读】

分布式一致性算法——共识性算法

分布式一致性算法-Paxos、Raft、ZAB、Gossip

Zookeeper——一致性协议:Zab协议 - 简书 (jianshu.com)

(6)数据分区

前面我们讨论的存储高可用架构都是基于硬件故障的场景去考虑和设计的,主要考虑当部分硬件可能损坏的情况下系统应该如何处理,但对于一些影响非常大的灾难或者事故来说,有可能所有的硬件全部故障。例如,新奥尔良水灾、美加大停电、洛杉矶大地震等这些极端灾害或者事故,可能会导致一个城市甚至一个地区的所有基础设施瘫痪,这种情况下基于硬件故障而设计的高可用架构不再适用,我们需要基于地理级别的故障来设计高可用架构,这就是数据分区架构产生的背景。

数据分区指将数据按照一定的规则进行分区,不同分区分布在不同的地理位置上,每个分区存储一部分数据,通过这种方式来规避地理级别的故障所造成的巨大影响。

设计一个良好的数据分区架构,需要从数据量的大小、具体的区域、分区的规则和复制的规则来具体考虑。

其中最重要的就是数据复制的规则,在某些异常或者灾难情况下,虽然部分数据受影响,但整体数据并没有全部被影响,本身就相当于一个高可用方案了。但仅仅做到这点还不够,因为每个分区本身的数据量虽然只是整体数据的一部分,但还是很大,这部分数据如果损坏或者丢失,损失同样难以接受。因此即使是分区架构,同样需要考虑复制方案。

常见的复制方法有集中式、互备式和独立式三种。

集中式:所有数据存在一个总备份中心,设计简单,但是成本较高,需要建设一个独立的备份中心。

image-20220313161156097

互备式:每个分区备份另外一个分区的数据,设计复杂,并且扩展麻烦,优点是成本低,因为每台机器都承载两个身份。

image-20220313161206002

独立式:每个分区自己有独立的备份中心【非本分区的】,优点是设计简单,各个分区互不影响,但是成本极高。

image-20220313161215359
updatedupdated2023-06-032023-06-03
加载评论