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

导读：《架构设计》系列为极客工夫李运华老师《从 0 开始学架构》课程笔记。本文为第五局部，次要介绍高可用存储架构，别离介绍了双机架构和集群架构以及各种具体计划的优缺点和利用场景。

扫描文末二维码 关注公众号 回复“架构设计”获取架构设计笔记残缺思维导图

双机架构

主备复制

其整体架构比较简单，主备架构中的“备机”次要还是起到一个备份作用，并不承当理论的业务读写操作，如果要把备机改为主机，须要人工操作。

长处

• 对于客户端来说，不须要感知备机的存在，即便劫难复原后，原来的备机被人工批改为主机后，对于客户端来说，只是认为主机的地址换了而已，毋庸晓得是原来的备机降级为主机。
• 对于主机和备机来说，单方只须要进行数据复制即可，毋庸进行状态判断和主备切换这类简单的操作。

毛病

• 备机仅仅只为备份，并没有提供读写操作，硬件老本上有节约。
• 故障后须要人工干预，无奈主动复原。

场景

主备复制是最常见也是最简略的一种存储高可用计划，简直所有的存储系统都提供了主备复制的性能，例如 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 开始学架构