数据高可用存储回顾

yolo_sec

于 2021-12-25 16:30:58 发布

阅读量1.8k

点赞数

分类专栏：学架构摘要文章标签：数据高可用存储

本文链接：https://blog.csdn.net/m0_60725291/article/details/122018183

版权

学架构摘要专栏收录该内容

37 篇文章 2 订阅

订阅专栏

存储高可用方案的本质都是通过将数据复制到多个存储设备，通过数据冗余的方式来实现高可用，其复杂性主要体现在如何应对复制延迟和中断导致的数据不一致问题。因此，对任何一个高可用存储方案，我们需要从以下几个方面去进行思考和分析：

数据如何复制？
各个节点的职责是什么？
如何应对复制延迟？
如何应对复制中断？

常见的高可用存储架构有主备、主从、主主、集群、分区。

主备复制

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

备机仅仅只为备份，并没有提供读写操作；
故障后需要人工干预，无法自动恢复；

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

主从复制

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

客户端需要感知主从关系，并将不同的操作发给不同的机器进行处理；
如果主从复制延迟比较大，业务会因为数据不一致出现问题；
故障时需要人工干预；

双机切换

主备复制和主从复制方案存在两个共性的问题：

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

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

要实现一个完善的切换方案，必须考虑这几个关键的设计点：

主备(从)之间状态传递的渠道，以及状态检测的内容；
双机切换决策:切换时机、切换策略、自动程度;
数据冲突解决，当原有故障的主机恢复后，新旧主机之间可能存在数据冲突；

互连式

互连式是指主备(从)机直接建立状态传递的渠道，存在状态传递通道故障的问题

要么对外提供统一地址，例如虚拟 IP，主机需要绑定这个虚拟的 IP；
或者客户端同时记录主备机的地址，哪个能访问就访问哪个，备机虽然能收到客户端的操作请求，但是会直接拒绝，拒绝的原因就是“备机不对外提供服务”；

中介式

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

虽然中介式在状态传递和状态决策上更加简单，但存在如何保证中介本身的高可用问题。如果中介自己宕机了，整个系统就进入了双备的状态，写操作相关的业务就不可用了。

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

模拟式

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

模拟式切换与互连式切换相比，优点是实现更加简单，因为省去了状态传递通道的建立和管理工作。

简单既是优点，同时也是缺点。因为模拟式读写操作获取的状态信息只有响应信息（例如，HTTP 404，超时、响应时间超过 3 秒等），没有互连式那样多样（除了响应信息，还可以包含 CPU 负载、I/O 负载、吞吐量、响应时间等），基于有限的状态来做状态决策，可能出现偏差。

主主复制

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

主主复制从总体上来看要简单很多，无须状态信息传递，也无须状态决策和状态切换，但是其对使用场景有限制，如果采取主主复制架构，必须保证数据能够双向复制，而很多数据是不能双向复制的。例如：

用户注册后生成的用户 ID，如果按照数字增长，那就不能双向复制，否则就会出现多台主机出现同一ID;
库存不能双向复制，一台主机减了，另一台主机也减了，复制后被覆盖掉；

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

数据集群

数据单机无法满足存储，需要更多机器分担，即集群是指多台机器组合在一起形成一个统一的系统。

根据集群中机器承担的不同角色来划分，集群可以分为两类：数据集中集群、数据分散集群。

数据集中集群

数据集中集群与主备、主从这类架构相似，我们也可以称数据集中集群为 1 主多备或者 1 主多从。

数据只能往主机中写

多条复制通道会增大主机复制的压力，某些场景下我们需要考虑如何降低主机复制压力，或者降低主机复制给正常读写带来的压力;
多条复制通道可能会导致多个备机之间数据不一致，某些场景下我们需要对备机之间的数据一致性进行检查和修正;
多台备机都需要对主机状态进行判断，而不同的备机判断的结果可能是不同的;
主机故障后，如何决定新的主机;

目前开源的数据集中集群以 ZooKeeper 为典型，ZooKeeper 通过 ZAB 算法来解决上述提到的几个问题

数据分散集群

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

算法需要考虑这些设计点：

均衡性：算法需要保证服务器上的数据分区基本是均衡的；
容错性：当出现部分服务器故障时，算法需要将原来分配给故障服务器的数据分区分配给其他服务器；
可伸缩性：当集群容量不够，扩充新的服务器后，算法能够自动将部分数据分区迁移到新服务器，并保证扩容后所有服务器的均衡性

在数据分散集群中，必须有一个角色来负责执行数据分配算法，这个角色可以是独立的一台服务器，也可以是集群自己选举出的一台服务器。

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

例如：HDFS的实现就是独立的服务器负责数据分区的分配，这台服务器叫作 Namenode，而Elasticsearch 集群则通过选举一台服务器来做数据分区的分配，叫作 master node。

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

数据分区

前面我们讨论的存储高可用架构都是基于硬件故障的场景去考虑和设计的，主要考虑当部分硬件可能损坏的情况下系统应该如何处理，但对于一些影响非常大的灾难或者事故来说，有可能所有的硬件全部故障。例如，地震，局部冲突等。我们需要基于地理级别的故障来设计高可用架构，这就是数据分区架构产生的背景。

数据分区指将数据按照一定的规则进行分区，不同分区分布在不同的地理位置上，每个分区存储一部分数据，通过这种方式来规避地理级别的故障所造成的巨大影响。即使某个地区发生严重的自然灾害或者事故，受影响的也只是一部分数据，而不是全部数据都不可用；当故障恢复后，其他地区备份的数据也可以帮助故障地区快速恢复业务。