架构师第六周

用户头像
Tulane
关注
发布于: 2020 年 07 月 15 日

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一致



用户头像

Tulane

关注

还未添加个人签名 2018.09.18 加入

还未添加个人简介

评论

发布
暂无评论
架构师第六周