架构设计 5-高可用架构之高可用存储架构

扫描左侧二维码 关注公众号 回复 “架构设计” 获取架构设计笔记完整思维导图

双机架构

主备复制

其整体架构比较简单,主备架构中的“备机”主要还是起到一个备份作用,并不承担实际的业务读写操作,如果要把备机改为主机,需要人工操作。

优点

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

缺点

  • 备机仅仅只为备份,并没有提供读写操作,硬件成本上有浪费。
  • 故障后需要人工干预,无法自动恢复。

场景

主备复制是最常见也是最简单的一种存储高可用方案,几乎所有的存储系统都提供了主备复制的功能,例如 MySQL、Redis、MongoDB 等

主从复制

主机负责读写操作,从机只负责读操作,不负责写操作。

优点

  • 主从复制在主机故障时,读操作相关的业务可以继续运行。
  • 主从复制架构的从机提供读操作,发挥了硬件的性能。

缺点

  • 主从复制架构中,客户端需要感知主从关系,并将不同的操作发给不同的机器进行处理,复杂度比主备复制要高。
  • 主从复制架构中,从机提供读业务,如果主从复制延迟比较大,业务会因为数据不一致出现问题。
  • 故障时需要人工干预。

场景

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

主主复制

主主复制指的是两台机器都是主机,互相将数据复制给对方,客户端可以任意挑选其中一台机器进行读写操作。

优点

  • 两台都是主机,不存在切换的概念
  • 客户端无须区分不同角色的主机,随便将读写操作发送给哪台主机都可以。

缺点

如果采取主主复制架构,必须保证数据能够双向复制,而很多数据是不能双向复制的,如:

  • 用户注册后生成的用户 ID,如果按照数字增长,那就不能双向复制
  • 库存不能双向复制

场景

主主复制架构对数据的设计有严格的要求,一般适合于那些临时性、可丢失、可覆盖的数据场景。例如,用户登录产生的 session 数据(可以重新登录生成)、用户行为的日志数据(可以丢失)、论坛的草稿数据(可以丢失)等。

双机切换

设计关键

主备复制和主从复制方案共性的问题

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

完善的切换方案,关键设计点

  • 主备间状态判断
    • 状态传递的渠道:是相互间互相连接,还是第三方仲裁?
    • 状态检测的内容:例如机器是否掉电、进程是否存在、响应是否缓慢等。
  • 切换决策
    • 切换时机:什么情况下备机应该升级为主机?是机器掉电后备机才升级,还是主机上的进程不存在就升级,还是主机响应时间超过 2 秒就升级,还是 3 分钟内主机连续重启 3 次就升级等。
    • 切换策略:原来的主机故障恢复后,要再次切换,确保原来的主机继续做主机,还是原来的主机故障恢复后自动成为新的备机?
    • 自动程度:切换是完全自动的,还是半自动的?例如,系统判断当前需要切换,但需要人工做最终的确认操作
  • 数据冲突解决
    • 当原有故障的主机恢复后,新旧主机之间可能存在数据冲突

常见架构

互连式

互连式就是指主备机直接建立状态传递的渠道,在主备复制的架构基础上,主机和备机多了一个“状态传递”的通道,这个通道就是用来传递状态信息的。

  • 可以是网络连接(例如,各开一个端口),也可以是非网络连接(用串口线连接)
  • 可以是主机发送状态给备机,也可以是备机到主机来获取状态信息。
  • 可以和数据复制通道共用,也可以独立一条通道。
  • 状态传递通道可以是一条,也可以是多条,还可以是不同类型的通道混合

客户端影响

  • 为了切换后不影响客户端的访问,主机和备机之间共享一个对客户端来说唯一的地址。例如虚拟 IP,主机需要绑定这个虚拟的 IP
  • 客户端同时记录主备机的地址,哪个能访问就访问哪个;备机虽然能收到客户端的操作请求,但是会直接拒绝,拒绝的原因就是“备机不对外提供服务”

缺点

  • 如果状态传递的通道本身有故障(例如,网线被人不小心踢掉了),那么备机也会认为主机故障了从而将自己升级为主机,而此时主机并没有故障,最终就可能出现两个主机。
  • 虽然可以通过增加多个通道来增强状态传递的可靠性,但这样做只是降低了通道故障概率而已,不能从根本上解决这个缺点,而且通道越多,后续的状态决策会更加复杂,因为对备机来说,可能从不同的通道收到了不同甚至矛盾的状态信息。

中介式

中介式指的是在主备两者之外引入第三方中介,主备机之间不直接连接,而都去连接中介,并且通过中介来传递状态信息

优点

  • 连接管理更简单:主备机无须再建立和管理多种类型的状态传递连接通道,只要连接到中介即可,实际上是降低了主备机的连接管理复杂度。
  • 状态决策更简单:主备机的状态决策简单了,无须考虑多种类型的连接通道获取的状态信息如何决策的问题,只需要按照下面简单的算法即可完成状态决策。
    • 无论是主机还是备机,初始状态都是备机,并且只要与中介断开连接,就将自己降级为备机,因此可能出现双备机的情况。
    • 主机与中介断连后,中介能够立刻告知备机,备机将自己升级为主机。
    • 如果是网络中断导致主机与中介断连,主机自己会降级为备机,网络恢复后,旧的主机以新的备机身份向中介上报自己的状态。
    • 主备机与中介连接都正常的情况下,按照实际的状态决定是否进行切换。例如,主机响应时间超过 3 秒就进行切换,主机降级为备机,备机升级为主机即可。

缺点

  • 虽然中介式架构在状态传递和状态决策上更加简单,但并不意味着这种优点是没有代价的,其关键代价就在于如何实现中介本身的高可用。如果中介自己宕机了,整个系统就进入了双备的状态,写操作相关的业务就不可用了

场景

  • MongoDB 的 Replica Set 采取的就是这种方式
  • 开源方案已经有比较成熟的中介式解决方案,例如 ZooKeeper 和 Keepalived。ZooKeeper 本身已经实现了高可用集群架构,因此已经帮我们解决了中介本身的可靠性问题,在工程实践中推荐基于 ZooKeeper 搭建中介式切换架构。

模拟式

模拟式指主备机之间并不传递任何状态数据,而是备机模拟成一个客户端,向主机发起模拟的读写操作,根据读写操作的响应情况来判断主机的状态。

优点

  • 对比一下互连式切换架构,我们可以看到,主备机之间只有数据复制通道,而没有状态传递通道,备机通过模拟的读写操作来探测主机的状态,然后根据读写操作的响应情况来进行状态决策。
  • 模拟式切换与互连式切换相比,优点是实现更加简单,因为省去了状态传递通道的建立和管理工作。

缺点

  • 模拟式读写操作获取的状态信息只有响应信息(例如,HTTP 404,超时、响应时间超过 3 秒等),没有互连式那样多样(除了响应信息,还可以包含 CPU 负载、I/O 负载、吞吐量、响应时间等),基于有限的状态来做状态决策,可能出现偏差。

集群&分区

集中集群

  • 数据集中集群与主备、主从这类架构相似,我们也可以称数据集中集群为 1 主多备或者 1 主多从
  • 无论是 1 主 1 从、1 主 1 备,还是 1 主多备、1 主多从,数据都只能往主机中写,而读操作可以参考主备、主从架构进行灵活多变

复杂度

  • 主机如何将数据复制给备机主
    • 主备和主从架构中,只有一条复制通道,而数据集中集群架构中,存在多条复制通道。
    • 多条复制通道首先会增大主机复制的压力,某些场景下我们需要考虑如何降低主机复制压力,或者降低主机复制给正常读写带来的压力。
    • 多条复制通道可能会导致多个备机之间数据不一致,某些场景下我们需要对备机之间的数据一致性进行检查和修正。
  • 备机如何检测主机状态
    • 在数据集中集群架构中,多台备机都需要对主机状态进行判断,而不同的备机判断的结果可能是不同的,如何处理不同备机对主机状态的不同判断,是一个复杂的问题。
  • 主机故障后,如何决定新的主机
    • 在数据集中集群架构中,有多台备机都可以升级为主机,但实际上只能允许一台备机升级为主机,那么究竟选择哪一台备机作为新的主机,备机之间如何协调,这也是一个复杂的问题。

分散集群

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

复杂度:

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

  • 均衡性:算法需要保证服务器上的数据分区基本是均衡的,不能存在某台服务器上的分区数量是另外一台服务器的几倍的情况
  • 容错性:当出现部分服务器故障时,算法需要将原来分配给故障服务器的数据分区分配给其他服务器。
  • 可伸缩性:当集群容量不够,扩充新的服务器后,算法能够自动将部分数据分区迁移到新服务器,并保证扩容后所有服务器的均衡性

数据分散集群和数据集中集群的不同点

  • 数据分散集群中的每台服务器都可以处理读写请求,因此不存在数据集中集群中负责写的主机那样的角色
  • 数据分散集群中,必须有一个角色来负责执行数据分配算法,这个角色可以是独立的一台服务器,也可以是集群自己选举出的一台服务器
  • 如果是集群服务器选举出来一台机器承担数据分区分配的职责,则这台服务器一般也会叫作主机,但我们需要知道这里的“主机”和数据集中集群中的“主机”,其职责是有差异的。
  • 数据集中集群架构中,客户端只能将数据写到主机;数据分散集群架构中,客户端可以向任意服务器中读写数据

场景

  • 数据集中集群适合数据量不大,集群机器数量不多的场景:ZooKeeper 集群,一般推荐 5 台机器左右,数据量是单台服务器就能够支撑;
  • 数据分散集群,由于其良好的可伸缩性,适合业务数据量巨大、集群机器数量庞大的业务场景:Hadoop 集群、HBase 集群,大规模的集群可以达到上百台甚至上千台服务器。

分区

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

设计一个良好的数据分区架构,需要从多方面去考虑

数据量

数据量的大小直接决定了分区的规则复杂度

分区规则

地理位置有近有远,因此可以得到不同的分区规则

  • 洲际分区:主要用于面向不同大洲提供服务,由于跨洲通讯的网络延迟已经大到不适合提供在线服务了,因此洲际间的数据中心可以不互通或者仅仅作为备份
  • 国家分区:主要用于面向不同国家的用户提供服务,不同国家有不同语言、法律、业务等,国家间的分区一般也仅作为备份
  • 城市分区:由于都在同一个国家或者地区内,网络延迟较低,业务相似,分区同时对外提供服务,可以满足业务异地多活之类的需求

复制规则

集中式:集中式备份指存在一个总的备份中心,所有的分区都将数据备份到备份中心

  • 设计简单,各分区之间并无直接联系,可以做到互不影响
  • 扩展容易,如果要增加第四个分区,只需要将该分区的数据复制到已有备份中心即可,其他分区不受影响。
  • 成本较高,需要建设一个独立的备份中心

互备式:指每个分区备份另外一个分区的数据

  • 设计比较复杂,各个分区除了要承担业务数据存储,还需要承担备份功能,相互之间互相关联和影响。
  • 扩展麻烦,新增节点需要调整已有几点
  • 成本低,直接利用已有的设备。

独立式:指每个分区自己有独立的备份中心,需要特别注意,各个分区的备份并不和原来的分区在一个地方

  • 设计简单,各分区互不影响。
  • 扩展容易,新增加的分区只需要搭建自己的备份中心即可。
  • 成本高,每个分区需要独立的备份中心,备份中心的场地成本是主要成本,因此独立式比集中式成本要高很多。

reference

  1. 从 0 开始学架构