6.7Doris 分析案例 (二): 高可用和集群扩容设计
高可用关注点：在服务器宕机时，如何保证数据是高可用的？数据能够正常访问？分布式集群如何做到水平伸缩--当存储空间不够时，能够很轻松向集群中添加服务器，向外提供服务能力？
高可用：数据一定要有多个备份。因为：分布式系统，任何一个服务器都有可能宕机，硬盘可能被损坏，CPU 可能停机---造成服务器不可用，数据永久丢失。
如果数据备份一份，就有可能永久丢失，无法恢复。所以：要保证数据的安全可靠，同时在任何服务器宕机的情况下，整个系统整个集群，
依然能够对外提供数据读写访问服务，数据不丢失，一定要保证，数据有多个备份。任何一个服务器宕机，有备份机还能够提供数据的读写操作。=====>这样才能保证分布式系统的高可用。
1.基本访问架构
对等 Node 访问
双写保证高可用性（W=2，R=1）
基于分区算法查找两个 Node
Copy 1 Node
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 仲裁
临时失效：
服务器升级或者网络不可用
失效机器在短时间内可恢复（例如：2 小时）
恢复后和失效前一致
永久失效：
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 加入
还未添加个人简介
评论