架构师第六周

Doris



核心点: 数据扩容 -> 支持透明化的扩容迁移



路由选择是分布式的核心



有状态的数据, 路由选择还需想到数据迁移



基于虚拟节点的分区算法



• 虚拟节点固定, 同一份数据只会hash到一个固定的虚拟节点

• 虚拟节点会绑定到物理节点上, 虚拟节点为10000个, 物理节点不超过100, 因为超过了会造成负载不均衡



• 集群扩容时, 仅需调整虚拟节点与物理节点的映射关系



扩容时的负载均衡平衡



• 保证扩容服务器时, 均衡分配

• 轮询, 先算出一个节点需要多少虚拟节点, 再轮询超过的, 划分给新增的服务器



集群管理



• ConfigServer 的心跳检测 (几秒一次, 太慢)

• KV Client 写DataServer 失败, 请求ConfigServer去写数据, ConfigServer写失败, 通知所有集群



瞬时失效 (秒级, 可恢复)



• KVClient 重试3次 (中间会sleep)

• 3次失败则升级到"仲裁临时失效"



临时失效 (不能由KVClient客户端决定)



• KVClient判断为临时失效, 提交给 ConfigServer仲裁

• ConfigServer重试3次

• ConfigServer失败后, 通知所有服务器



临时失效后的恢复



• 短时间内可恢复

• 恢复后数据和失效前一致

• 不能恢复则升级到永久失效



临时失效的fail over



• 原本是数据双写, 现在一个节点失效, 另一个节点正常读写

• 启用一个临时物理节点, 用于备份写

• 若临时失效的节点又恢复了, 将临时节点的备份数据写回恢复节点

• 此时恢复节点也接收写请求, 数据仍是双写, 但由于恢复节点数据不正确, 所以不能读

• 恢复节点的写入来源有请求写入, 备份写入, 需要根据时间戳来保证不冲突(冲突则丢弃旧的)





永久失效的fail over



• 若挂掉的节点起不来, 则备份节点丢弃, 使用空白的新节点

• 一直没问题的正常节点全拷贝到新节点

• 拷贝时的新节点其实也是临时失效状态, 需等待拷贝完成, 流程和临时失效failover一致