Doris 临时失效处理过程的 UML 时序图

针对Doris案例，请用UML时序图描述Doris临时失效的处理过程(包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程)。



Doris Chttps://github.com/itisaid/Doris)是一个海量分布式KV存储系统，其设计目标是支持中等规模高可用可伸缩的KV存储集群。跟主流的NoSQL系统HBase相比较CDoris0.1 VS HBase0.90)，Doris具有相似的性能和线性伸缩能力，并具有更好的可用性以及更友好的图形用户管理界面。

对于一个大规模集群的存储系统而言，服务器宕机、交换机失效是常态，架构师必须为这些故障发生时，保证系统依然可用而进行系统设计。系统架构层面，保证高可用的主要手段是一一冗余:服务器热备，数据多份存储。使整个集群在部分机器故障的情况下可以进行灵活的失效转移(Failover，保证系统整体依然可用，数据持久可靠。

Doris整体架构图见下：

系统整体上可分为三个部分

• 应用程序服务器:它们是存储系统的客户，对系统发起数据操作请求。

• 数据存储服务器:存储系统的核心，负责存储数据、响应应用服务器的数据操作请求。

• 管理中心服务器:这是一个由两台机器组成的主一主热备的小规模服务器集群，主要负责集群管理，对数据存储集群进行健康心跳检测;集群扩容、故障恢复管理;对应用程序服务器提供集群地址配置信息服务等。

其中数据存储服务器又根据应用的可用性级别可以设置数据复制份数，即每个数据实际物理存储的拷贝数目，复制份数越多，可用性级别越高，当然需要的服务器也越多。为了便于管理和访问数据的多个拷贝，将存储服务器划分为多个序列，数据的多个拷贝存储在不同的序列中(序列可以理解为存储集群中的子集群)。

应用服务器写入数据的时候，根据集群配置和应用可用性级别使用路由算法在每个序列中计算得到一台服务器，然后同时并发写入这些服务器中;应用服务器读取数据的时候，只需要随机选择一个序列，根据相同路由算法计算得到服务器编号和地址，即可读取。通常情况下，系统最少写入的拷贝份数是两份。



Doris系统调用时序模型图见下：



高可用的系统需要解决在不同故障情况下都保持较高的系统可用性，但是不同故障类型带来的问题复杂性不同，不可能使用一种解决方案处理所有情况，需要针对各种故障提供具体解决方案。

分布式存储系统的故障分类:

在讨论解决方案之前，我们先对故障进行分类，针对不同故障情况，分别处理对待。

对于一个分布式存储系统而言，影响系统整体可用性的故障可以分成三类:

• 瞬时故障:引起这类故障的主要原因是网络通讯瞬时中断;服务器内存垃圾回收或后台线程繁忙停止数据访问操作响应。其特点是故障时间短，在秒级甚至毫秒级系统即可自行恢复正常响应。

• 临时故障:引起这类故障的主要原因是交换机宕机、网卡松动等导致的网络通讯中断;系统升级、停机维护等一般运维活动引起的服务关闭;内存损坏、CPU过热等硬件原因导致的服务器宕机;这类故障的主要特点是需要人工干预(更换硬件、重启机器等)才能恢复正常。通常持续时间需要几十分钟甚至几小时。故障时间可分为两个阶段:临时故障期间，临时故障恢复期间。

• 永久故障:引起这类故障主要原因只有一个:硬盘损坏，数据丢失。虽然损坏硬盘和损坏内存一样，可以通过更换硬盘来重新启动机器，但是丢失的数据却永远找不回来，因此其处理策略也和前面两种故障完全不同，恢复系统到正常状态也需要更长的时间。故障时间可分为两个阶段:永久故障期间，永久故障恢复期间。



Doris临时失效处理过程的UML时序图见下：



1、应用服务器向存储服务器（序列1服务器NO.2）（故障）请求服务，发现超时

2、应用服务器再向存储服务器（序列1服务器NO.2）（故障）请求X次服务，发现超时

3、应用服务器将存储服务器（序列1服务器NO.2）（故障）的信息发送给管理中心进行仲裁，返回正常的存储服务器（序列2服务器NO.2）和临时备份服务器

4、应用服务器读数据（从正常的存储服务）正常的存储服务器（序列2服务器NO.2）

5、应用服务器写数据（从正常的存储服务）正常的存储服务器（序列2服务器NO.2）和临时备份服务器

6、存储服务器（序列1服务器NO.2）（故障）修复好的时候，由管理中心发送迁移备份数据通知给临时备份服务器进行数据迁移，临时备份服务器将发送存储服务器（序列1服务器NO.2）进行数据迁移

7、数据迁移完时，临时备份服务器通知存储服务器（序列1服务器NO.2）进行数据恢复，存储服务器（序列1服务器NO.2）根据日志数据（时间戳）进行恢复数据，恢复完成并通知管理中心

8.应用服务器正常读写存储服务器（序列1服务器NO.2）和存储服务器（序列2服务器NO.2）