极客大学架构师训练营 系统架构 分布式数据库 Zookeeper 第 12 课 听课总结

发布于: 8 小时前

说明

讲师:李智慧

架构师要有设计、并开发出分布式数据库。仅仅是会用的话,竞争力是不够的。像阿里巴巴、腾讯、京东都有自己的分布式数据库开发团队,要想进入这个团队当架构师,就要有这种视野。

在公司里面,你要是听别人的,那么基本上都是把重复的、没有技术含量的活分配给你。人生的机会,都是自己去争取的。

作为架构师,要传递一个信息,打动公司,让公司支持你不赚钱的项目。你要有技术影响力,争取说服领导支持去你做这个事情,并且能够说服团队跟你一起干。

分布式一致性 ZooKeeper

分布式系统脑裂

在一个分布式系统中,不同服务器获得了互相冲突的数据信息或者执行指令,导致整个集群陷入混乱,数据损坏,统一称作分布式系统脑裂。

数据库主主备份

分布式一致性算法 Paxos

三个角色

  • Proposer

  • Acceptor

  • Learner

  1. 第一阶段:Prepare阶段。Proposer向Acceptors发出Prepare请求,Acceptors针对收到的Prepare请求进行Promise承诺。

  2. 第二阶段:Accept阶段。Proposer收到多数Acceptors承诺的Promise后,向Acceptors发出Propose请求,Acceptors针对收到的Propose请求进行Accept处理。

  3. 第三阶段:Learn阶段。Proposer在收到多数Acceptors的Accept之后,标志着本次Accept成功,决议形成,将形成的决议发送给所有Learners。

Proposer生成全局唯一且递增的Proposal ID(可使用时间戳Server ID),向所有Acceptors发送Prepare请求,这里无需携带提案内容,只携带Proposal ID即可。

Acceptors收到Prepare和Propose请求后

  1. 不再接受Proposal ID小于等于当前请求的Prepare请求。

  2. 不再接受Proposal ID小于等于当前请求的Propose请求。

ZooKeeper 架构

ZooKeeper 树状记录结构

ZooKeeper API

String create(path, data, acl, flags);
void delete(path, expectedVersion);
Stat setData(path, data, extectedVersion);
(data, Stat) getData(path, watch);
Stat exists(path, watch);
String[] getChildren(path, watch)
void sync(path)
List multi(ops)

配置管理

  • Administrator:setData("/config/param1", "value", -1)

  • Consumer:getData("/config/param1", true)

选 Master (Leader)

1. getdata("/servers/leader", true)

2. if successful follow the leader described in the data and exit

3. create("/servers/leader", hostname, EPHEMERAL)

4. if successful lead and exit

5. goto step 1

选 Master/ Leader (Python)

handle = zookeeper.init("localhost:2181", my_connection_watcher, 10000, 0)
(data, stat) = zookeeper.get(handle, "/app/leader", True);
if (stat == None)
path = zookeeper.create(handle, "/app/leader", hostname:info, [ZOO_OPEN_ACL_UNSAFE], zookeeper.EPHEMERAL)
if (path == None)
(data, stat) = zookeeper.get(handle, "/app/leader", True)
# someone else is the leader
# parse the string path that contains the leader address
else
# we are the leader continue leading
else
# someone else is the leader
# parse the string path that contains the leader address

集群管理(负载均衡与失效转移)

Monitoring process:

  1. Watch on/nodes

  2. On watch trigger do getChildren(/nodes, true)

  3. Track which nodes have gone away

Each Node:

  1. Create /nodes/node-${i} as ephemeral nodes

  2. Keep updating /nodes/node-${i} periodically for node status changes (status updates could be load/iostat/cpu/others)

ZooKeeper 性能

  • 读的能力要远远高于写的能力。这是因为写的时候要最终选举一个结果,读的时候,随便读一个服务器就好。

  • 服务器越多,写的时候投票数就越大,写速度就越慢。

  • 服务器都是基数台服务器部署,投票容易产生最大数。

Zab 协议

商用都是简化版的ZooKeeper协议 - Zab协议。更简单,性能更高。

当Leader宕机以后,会有一段时间没有响应,Follower中会重新选举一位Leader,投票给服务器id最大的服务器。

Doris - 海量 KV Engine

当前现状

网站关键业务有许多海量KV数据存储和访问需求。

  1. **站 UDAS 使用。

  • 存在问题:扩容困难、写性能较低、实时性低等

  1. 网站有多套KV方案,接口不统一,运维成本高。

  • **站 USAS - BDB

  • **站:TT

  1. 飞天 KV Engine (Aspara)问题。

  • 使用复杂

  • 性能较低

产品需求

产品定位:海量分布式透明化KV存储引擎。

解决问题:

  • 替换 UDAS:解决扩容迁移复杂,维护困难的问题。

  • **站海量 KV 数据存储

☞ Global SEO, 1亿 Product,2.4T 数据量

☞ 2011年底:3.1 T

  • **站

☞ WholeSale Global SEO

☞ Product 数:1600w,2.8T

☞ 2011年底:3400w,5.8T

  • **站

☞ 风控用户行为日志:每月2亿,40G,增长很快。

案例:有个微信用户30w在钱包里冻结了,就打电话给微信客服,微信客服回答:“你的钱是你的钱,但微信是微信的。不用慌,我们会帮你解决的。” 在分布式系统里面,数据最终是会一致的。

产品目标

  1. 产品目标:

* KV 存储 Engine

* 逻辑管理:Namespace

* 二级索引

  1. 非功能目标

* 海量存储:<font color='red'>透明集群管理,存储可替换</font>

* 伸缩性:<font color='red'>线性伸缩,平滑扩容</font>

* 高可用:自动容错和故障转移

* 高性能:低响应时间,高并发

* 扩展性:灵活扩展新功能

* <font color='red'>低运维成本</font>

☞ <font color='red'>易管理</font>

☞ <font color='red'>可监控</font>

  1. 约束

* 一致性:最终一致性

技术指标

目标 | 指标 | 说明

---| --- | ---

集群规模| 4 - 100 + Machine | -

容量| 100T+(取决于硬件规模) | B2B 所有KV存储场景

可用性| 99.99 + 7% | -

持久性 | 10个9 | -

伸缩性、平滑扩容 | 不停机扩容完成时间 约= 单 Node 迁移时间 (10台扩1台场景)总数据=2.4T 单Node迁移量=240G/10 = 24G 迁移时间=24G/33M = 12分钟 | 10 + 1 场景

高性能 | Read: < 8ms (Aspara:10ms); Write: < 10 ms (Aspara: 10ms) (高于 Aspara, 国际站 SEO 需求,高并发场景) | -

逻辑架构

  • 二层架构 - Client、DataServer + Store

  • 四个核心组件 - Client、DataServer、Store、Administration

KV Storage 概念模型

  • Machine:物理机

  • Node: 分区单元,一台 Machine 可运行多个 Node。

  • Namespace:数据的逻辑划分 Tag,Client 可识别。数据管理无需识别。

关键技术点 - 数据分区

  • 解决海量数据存储

  • 客户端计算分区

  • 分区算法(Partition Policy)

  • Client 向 Config Server 抓取分区配置

基于虚拟节点的分区算法

  • 均衡性:数据分布均衡

  • 波动性:X/(M+X), 优于一致性 Hash 的 X/M.

<font color='red'>作为架构师,当有人质疑你的时候,说明有人关注你,说明是好事。那么你就要用设计方案,用数据去证明你的架构更优。就像网红一样,不管是好消息、还是坏消息都是好事情,说明有人关注你。当你能得到马云的质疑,那么说明你的人生就走上巅峰了。</font>

物理节点由2个扩充到3个,映射关系变化

每个虚拟节点对应两个对等物理节点。(最终公式的效果不好,换为别的公式解决。)

基本访问架构

  1. 对等 Node 访问

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

  3. 基于分区算法查找两个 Node

  • Copy 1 Node

  • Copy 2 Node

  1. 数据恢复和数据同步

  • Redo Log

  • Update Log

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

  1. 检查1:ConfigServer 对DataServer心跳检查

  2. 检查2:Client 访问时 Fail 报告

  3. 其它Client定时配置抓取

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

  1. 瞬时失效

  2. 临时失效

* 服务器升级或者网络暂时不可用

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

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

  1. 永久失效

* 机器下线

关键技术点 - 临时失效的 fail over

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

  2. 物理节点X:备用节点,临时存放失效的物理节点2的数据,物理节点2恢复后迁移回物理节点2.

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

关键技术点 - 永久失效 failover

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

一致性处理:version(timestamp)

  • Conflict Check & Merge

关键技术点 - 扩容实施数据迁移:基本原理

  1. 集群扩容,新增 Node X.

  2. 旧路由算法:Route1(key1)={pn1, pn2}

  3. 新路由算法: Route1(key1)={pn1, pnx}

  4. 新旧算法有一个Node相同,因此只需要迁移一个Node.

Pn2 数据迁移到pnx, client不再对pn2数据操作

  • R操作只在pn1 上

  • W/R 操作指向{pn1, pnx}

Client 对等节点中的一个pn1不变(路由算法保证)

关键技术点 - 扩容实施数据迁移:迁移过程

基本原理:基于遍历的路由对比迁移(描述见备注)

  • 迁移时,计算两个 Route 算法,不相同则迁移。

  • 采用改进的分区路由算法,减少迁移量:X(M+X)

数据可识别功能 - 逻辑数据结构

  1. Namespace:一个业务实体数据的集合

  2. Data Definition

☞ Namespace的MetaData数据结构定义,满足“数据定义可描述”的需求。

Doris 和平台产品关系

产品规划(功能和版本)

目标 | 功能/特性 | 一期(Q2)| 二期 | 三期

-- | -- | -- | -- | --

功能 | 数据模型 | Key-Value 模型, Namespace,数据结构可描述 | 二级索引 | Column

  • | 数据访问和 KVClient | KV API Client调用框架数据通信 | - | -

非功能性 | 分区和线性伸缩 | 分区路由算法 | - | -

  • | 可用性 | W2, Failover | - | -

  • | 透明集群管理 | 状态报告,配置抓取 | 集成Normandy配置推送 | -

  • | 扩容 | 实时平滑扩容 | - | -

  • | 存储方案 | StoreDriver、BDB实现 | MySql/TT | -

管理和运维 | 监控 | 集群管理、基本集群监控(接入Dragoon) | 硬件监控(接入Dragoon) | -

  • | 备份与恢复 | Store原生方案 | - | -

Doris Q2 研发计划 - 功能需求

数据模型

  • Key-Value 结构

  • Namespace 支持

数据访问

  • 基本KV API规范

  • KV Client:抽象API,调用框架

  • 高性能通信

Doris Q2 研发计划

非功能需求

  • 分区和线性伸缩:改进的分区路由算法

  • 可用性:对等Node,写2,Failover

  • 透明集群管理和配置抓取

  • 实时平滑扩容

  • 存储可替换和 BDB 实现

管理和运维

  • 集群管理

  • 基本集群监控(接入 Dragoon)

实施计划 Q3 - Q4

** (Product多语言)

  • 业务范围:Product,产品摘要,产品描述,产品属性,Company

  • 当前UDAS 支持情况

☞ 数据量:2.4T,Product数1亿,机器:10台

☞ 商业PV:800w,KV PV:1.08亿,14ms-100ms,TPS:250

  • 2011年底:产品数和存储量 +30%,3.1T

**

  • Product数:1600w

  • 存储量:2.8T

  • 2011年底:Product 3400w,5.8T

发布于: 8 小时前 阅读数: 4
用户头像

John(易筋)

关注

问渠那得清如许?为有源头活水来 2018.07.17 加入

前阿里巴巴资深无线开发,目前汇丰银行专家。架构师,全栈工程师。擅长算法、数据结构、设计模式、iOS、Java、 Spring Boot、Spring Cloud、Docker

评论

发布
暂无评论
极客大学架构师训练营 系统架构 分布式数据库 Zookeeper 第12课 听课总结