说明
讲师：李智慧
架构师要有设计、并开发出分布式数据库。仅仅是会用的话，竞争力是不够的。像阿里巴巴、腾讯、京东都有自己的分布式数据库开发团队，要想进入这个团队当架构师，就要有这种视野。
在公司里面，你要是听别人的，那么基本上都是把重复的、没有技术含量的活分配给你。人生的机会，都是自己去争取的。
作为架构师，要传递一个信息，打动公司，让公司支持你不赚钱的项目。你要有技术影响力，争取说服领导支持去你做这个事情，并且能够说服团队跟你一起干。
分布式一致性 ZooKeeper
分布式系统脑裂
在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个集群陷入混乱，数据损坏，统一称作分布式系统脑裂。
数据库主主备份
分布式一致性算法 Paxos
三个角色
ProposerAcceptorLearner 第一阶段：Prepare阶段。Proposer向Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行Promise承诺。第二阶段：Accept阶段。Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，Acceptors针对收到的Propose请求进行Accept处理。第三阶段：Learn阶段。Proposer在收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有Learners。
Proposer生成全局唯一且递增的Proposal ID（可使用时间戳Server ID），向所有Acceptors发送Prepare请求，这里无需携带提案内容，只携带Proposal ID即可。
Acceptors收到Prepare和Propose请求后
4. 不再接受Proposal ID小于等于当前请求的Prepare请求。
5. 不再接受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）
getdata("/servers/leader", true)if successful follow the leader described in the data and exitcreate("/servers/leader", hostname, EPHEMERAL)if successful lead and exitgoto 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 addresselse# we are the leader continue leadingelse# someone else is the leader# parse the string path that contains the leader address
集群管理（负载均衡与失效转移）
Monitoring process:
Watchon/nodesOn watch trigger dogetChildren(/nodes, true)Track which nodes have gone away
Each Node:
Create/nodes/node-${i}as ephemeral nodesKeep updating/nodes/node-${i}periodically for node status changes (status updates could beload/iostat/cpu/others)
ZooKeeper 性能
读的能力要远远高于写的能力。这是因为写的时候要最终选举一个结果，读的时候，随便读一个服务器就好。服务器越多，写的时候投票数就越大，写速度就越慢。服务器都是基数台服务器部署，投票容易产生最大数。Zab 协议
商用都是简化版的ZooKeeper协议 - Zab协议。更简单，性能更高。
当Leader宕机以后，会有一段时间没有响应，Follower中会重新选举一位Leader，投票给服务器id最大的服务器。
Doris - 海量 KV Engine
当前现状
网站关键业务有许多海量KV数据存储和访问需求。
**站 UDAS 使用。 存在问题：扩容困难、写性能较低、实时性低等 网站有多套KV方案，接口不统一，运维成本高。 **站 USAS - BDB**站：TT 飞天 KV Engine （Aspara）问题。 使用复杂性能较低
产品需求
产品定位：海量分布式透明化KV存储引擎。
解决问题：
替换 UDAS：解决扩容迁移复杂，维护困难的问题。**站海量 KV 数据存储
☞ Global SEO， 1亿 Product，2.4T 数据量
☞ 底：3.1 T**站
☞ WholeSale Global SEO
☞ Product 数：1600w，2.8T
☞ 底：3400w，5.8T**站
☞ 风控用户行为日志：每月2亿，40G，增长很快。
案例：有个微信用户30w在钱包里冻结了，就打电话给微信客服，微信客服回答：“你的钱是你的钱，但微信是微信的。不用慌，我们会帮你解决的。” 在分布式系统里面，数据最终是会一致的。
产品目标
产品目标： KV 存储 Engine逻辑管理：Namespace二级索引 非功能目标 海量存储：透明集群管理，存储可替换伸缩性：线性伸缩，平滑扩容高可用：自动容错和故障转移高性能：低响应时间，高并发扩展性：灵活扩展新功能低运维成本☞ 易管理
☞ 可监控 约束 一致性：最终一致性
技术指标
逻辑架构
二层架构 - Client、DataServer + Store四个核心组件 - Client、DataServer、Store、AdministrationKV Storage 概念模型
Machine：物理机Node: 分区单元，一台 Machine 可运行多个 Node。Namespace：数据的逻辑划分 Tag，Client 可识别。数据管理无需识别。关键技术点 - 数据分区
解决海量数据存储客户端计算分区分区算法（Partition Policy）Client 向 Config Server 抓取分区配置基于虚拟节点的分区算法
均衡性：数据分布均衡波动性：X/(M+X), 优于一致性 Hash 的 X/M.作为架构师，当有人质疑你的时候，说明有人关注你，说明是好事。那么你就要用设计方案，用数据去证明你的架构更优。就像网红一样，不管是好消息、还是坏消息都是好事情，说明有人关注你。当你能得到马云的质疑，那么说明你的人生就走上巅峰了。
物理节点由2个扩充到3个，映射关系变化
每个虚拟节点对应两个对等物理节点。（最终公式的效果不好，换为别的公式解决。）
基本访问架构
对等 Node 访问双写保证可用性（W=2, R=1）基于分区算法查找两个 Node Copy 1 NodeCopy 2 Node 数据恢复和数据同步 Redo LogUpdate Log集群管理 - 健康检查和配置抓取
检查1：ConfigServer 对DataServer心跳检查检查2：Client 访问时 Fail 报告其它Client定时配置抓取关键技术点 - 可用性关键场景
瞬时失效临时失效 服务器升级或者网络暂时不可用失效机器在短时内可恢复（例如：2小时内）恢复后数据和失效前一致 永久失效 机器下线关键技术点 - 临时失效的 fail over
物理节点2临时失效，并在可接受时间内恢复。物理节点X：备用节点，临时存放失效的物理节点2的数据，物理节点2恢复后迁移回物理节点2.物理节点2临时失效及恢复期间物理节点1承担所有read操作。关键技术点 - 永久失效 failover
每份 Data 写两份保证高可用：Copy1，Copy2
一致性处理：version（timestamp）
Conflict Check & Merge
关键技术点 - 扩容实施数据迁移：基本原理
集群扩容，新增 Node X.旧路由算法：Route1(key1)={pn1, pn2}新路由算法：Route1(key1)={pn1, pnx}新旧算法有一个Node相同，因此只需要迁移一个Node.Pn2 数据迁移到pnx, client不再对pn2数据操作
R操作只在pn1 上W/R 操作指向{pn1, pnx}
Client 对等节点中的一个pn1不变（路由算法保证）
关键技术点 - 扩容实施数据迁移：迁移过程
基本原理：基于遍历的路由对比迁移（描述见备注）
迁移时，计算两个 Route 算法，不相同则迁移。采用改进的分区路由算法，减少迁移量：X(M+X)
数据可识别功能 - 逻辑数据结构
Namespace：一个业务实体数据的集合Data Definition☞ Namespace的MetaData数据结构定义，满足“数据定义可描述”的需求。
Doris 和平台产品关系
产品规划（功能和版本）
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底：产品数和存储量 +30%，3.1T
站**
Product数：1600w存储量：2.8T底：Product 3400w，5.8T
