简介

Doris(https://github.com/itisaid/Doris)是一个海量分布式 KV 存储系统，其设计目 标是支持中等规模高可用可伸缩的 KV 存储集群。

Doris 可以实现海量存储，线性伸缩、平滑扩容，自动容错、故障转移，高并发，且运维成本低。部署规模，建议部署 4-100+台服务器。

逻辑架构

Doris 采用两层架构，Client 和 DataServer+Store。

有四个核心组件，Client、DataServer、Store、Administration。

应用程序通过 Client SDK 进行 Doris 的访问，

每台服务器上部署一个 Data Sever 做服务器的管理，每台服务器上有自己的存储 Store，整个集群的数据存储，每台机器独立部署。数据通过路由选择写入到不同的机器中。

Administration 为管理中心，提供配置、管理和监控。

config 指，应用程序启动一个 Data Server，在启动时要配置管理中心的 ip 地址，通关管理中心。管理中心会修改配置项感知到集群中加了新机器，对新机器管理，扩容等。待机器处于可用状态，将该机器的配置项通知给 KV Client。从而 KV Client 进行新的路由选择。

扩容、下线机器等的控制台界面通过 Management 管理。

Monitor 监控机器是否正常。

KV Storage 概念模型

client 写数据，绑定产品的 namespace（逻辑隔离），构成新 key，路由到具体机器上读写。

路由解析算法是设计的一个关键点，决定集群的管理方式，也决定了集群扩容的复杂性和难度。

Doris 的算法类似 redis，有桶的概念，key 映射到 1w 个虚拟节点，虚拟节点在映射到物理节点。

由于 Doris 设计时，用于 4-100+规模的集群。因此，Doris 分了 1w 个虚拟节点，当服务器超过 100 会导致负载不均衡，1000 会更差，相当于每一个集群上有 10 个虚拟节点，虚拟节点会有 10%的影响。

扩容时，需要调节虚拟节点指向新的位置。具体过程为，暴利轮询新节点添加后，一个服务器上应该承载的虚拟节点个数，将超出的虚拟节点迁移到新机器即可。如上图左图有 2 个物理节点，扩容后，有 3 个物理节点，变为右图。

基本访问架构

为了保证高可用。doris 所有服务分成 2 个组，两组服务器对等。两个 group 是可以有不同数量的服务器。

写操作时，client 的路由算法在两个 group 分别选 2 个服务器，分别（同时）写入，两个服务器全部返回后，再继续向下进行。读操作时，从两个服务器随机选一个读。这样，提高可用性，数据持久性，不会丢失。

监控检测

集群管理的重要角色 Config Server，有一个功能是负责发现故障服务器。

发现故障的方式有 2 种：

1. ConfigServer 对 DataServer 心跳检测

2. Client 访问时 Fail 报告

通常心跳检测是慢的，几秒进行一次心跳检测。更多时候，是 client Fail 失败报告发现无效服务器，当写入失败时，Client 会告诉 Config Server。Config Server 校验，也访问失败，则通知其他 client。

可用性关键场景

节点失效分为：瞬间失效、临时失效、永久失效

应用服务器向服务器写，如果写失败，为瞬间失效。接着应用服务器进行 3 次重试。3 次都失败，通知管理服务器，进行服务的失效判断。

管理服务器再写一次，如果写成功，认为是客户端自己通信通信问题。如果写入失败，判断为临时失效，通知所有 client，服务器失效，不要写，也不读。

如果 2 小时恢复，则节点为临时失效。如果 2 小时没有恢复，认为是永久失效。

临时失效的恢复

如图，如果节点 2 失效，进入临时失效阶段。

将数据写入节点 1 同时，写入备份节点，等待节点 2 恢复，如左图。

注意，这里两个节点写入的数据是不同的。节点 1 记录的操作结果，而备份节点，类似 binlog，记录操作过程。

节点 2 恢复后，从备份节点，将之前的操作迁移到节点 2。恢复过程中，节点 2 只写不读。数据冲突时，根据时间戳检测。所有数据处理完成后，节点 2 进入正常状态。如右图。

永久失效的恢复

如图，节点 2 临时失效 2 个小时还未恢复，判定为永久失效。进入永久失效的恢复。

1. 删除临时失效期间在备份服务器上写入的数据。

2. 在集群里，找一个空白节点 3（stand by 节点），标记节点 3 临时失效状态，将节点 1 的内容拷贝到节点 3，此时节点 3 不写不读（因为是临时失效状态）。对节点 1 的写入，还是记录到备份节点。如左图所示。

3. 等待数据迁移完成，进入失效恢复状态，节点 3 写数据，并从日志节点恢复数据。如右图。

4. 数据恢复完成后，节点 3 进入正常状态。节点 2 可以下掉了。

设计中，有临时日志节点（备份节点），有空白节点。实际使用中没有节点 3 空白节点。原因：1 自动迁移有风险，还是需要手动迁移。2 几年宕机 1 台，一直有一个空白节点 standby 浪费。一般晚上报警失效也没有事情，第二天，找机器扩容即可。认为 24 小时之内，同样编号的 2 台机器连续 down 掉，概率很低。

扩容数据迁移原理

物理节点分成 2 个 group，写的时候，向 2 个 group 同时写。当其中一个 group 扩容机器时，该 group 上的所有节点进入临时失效状态。停止读写，将数据迁移到新的服务器上。

由于是虚拟节点的映射在调整，所以迁移是按照虚拟节点调整。为了迁移方便，虚拟节点物理化，一个虚拟节点对应一个文件。迁移时其实就是拷贝文件。这时，如果 group1 有节点失效也会出现不一致，但是，通常扩容的过程很快，因为，是 scp 拷贝文件，瓶颈为网络带宽，通常几十 T 数据，几分钟迁移完成，十来分钟进行数据恢复。

参考：极客大学-架构师训练营