写点什么

6.7Doris 分析案例 (二): 高可用和集群扩容设计

用户头像
张荣召
关注
发布于: 2020 年 11 月 02 日

  高可用关注点:在服务器宕机时,如何保证数据是高可用的?数据能够正常访问?分布式集群如何做到水平伸缩--当存储空间不够时,能够很轻松向集群中添加服务器,向外提供服务能力?

  高可用:数据一定要有多个备份。因为:分布式系统,任何一个服务器都有可能宕机,硬盘可能被损坏,CPU可能停机---造成服务器不可用,数据永久丢失。

               如果数据备份一份,就有可能永久丢失,无法恢复。所以:要保证数据的安全可靠,同时在任何服务器宕机的情况下,整个系统整个集群,

               依然能够对外提供数据读写访问服务,数据不丢失,一定要保证,数据有多个备份。任何一个服务器宕机,有备份机还能够提供数据的读写操作。=====>这样才能保证分布式系统的高可用。

1.基本访问架构

对等Node访问

双写保证高可用性(W=2,R=1)

基于分区算法查找两个Node

  1. Copy 1 Node

  2. Copy 2 Node

数据恢复和数据同步

       1. Redo Log

       2. Update Log

            

解析:Doris默认策略----写2份/读1份

          Doris集群分为2个Group(A,B)-----20台服务器构成集群,每个Group有10台服务器

          写2份:同时向2个Group(A,B)写数据----Doris要求两份都要成功--只有一份成功--失效处理。(Cassandra写三份:2个写入成功,便认为成功)

          读1份:当A组Group某个服务器宕机,B组可以继续提供数据读服务

2.集群管理----健康检查和配置抓取

检查1:ConfigServer对DataServer心跳检查

检查2:Client访问时Fail报告,其他Client定时配置抓取

解析:状态判断不一致---------------Client1认为DataServer1不能写入,Client2认为DataServer2可以写入。如果client2写入数据,导致数据状态不一致。

          分布式集群中,状态的判断,需要统一处理。(zookeeper可以判断一台服务器是否宕机,是否可用,出现较晚)。引入仲裁机制---控制中心的ConfigServer决定。

健康检查流程:

1.写2份(A,B)。如果其中一份A失败(client不确定是否真的失败,要求配置中心给出反馈结果)。=====>通知ConfigServer配置中心(确认A是否真的失败)

 2.ConfigServer配置中心健康检查:ConfigServer也向A写入。如果写入A也失败,确认DataServer1宕机失效。修改配置项,标记DataServer1为失效状态。通知集群中所有客户端都不要向DataServer1写入数据。

3.关键技术点----可用性关键场景

瞬时失效:超时,连接终端,网络闪断,丢包----(可自我修复)----- 客户端重试3次----超过3次-----报告给ConfigServer仲裁

临时失效:

  1. 服务器升级或者网络不可用

  2. 失效机器在短时间内可恢复(例如:2小时)

  3. 恢复后和失效前一致

永久失效:

       1. 机器下线。

4.关键技术点--临时失效的Fail Over



解析:物理节点2临时失效,并在可接受时间内恢复。

          物理节点X:备用节点,临时存放失效的物理节点2的数据,物理节点2恢复后迁移会物理节点2(物理节点3:备份节点,保存日志,又叫日志节点)

          物理节点2临时失效机恢复期间物理节点1承担所有read操作。

          物理节点2恢复后,通知ConfigServer,标记恢复。所有客户端可访问。

5.关键技术点--永久失效的Fail Over

       每份Data写两份保证高可用:Copy1,Copy2

       一致性处理:version(timestamp)

           1. Conflict Check & Merge 



用户头像

张荣召

关注

还未添加个人签名 2018.05.02 加入

还未添加个人简介

评论

发布
暂无评论
6.7Doris分析案例(二):高可用和集群扩容设计