说明

讲师：李智慧

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

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

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

分布式一致性 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 leadingelse	# 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