分布式数据库

• MySQL复制

• 主从复制

• 主多从复制

• 优点

• 分摊负载

• 专机专用

• 便于冷备

• 高可用

• 主主复制

• 主主失效恢复

• 主主失效的维护过程

• MySQL复制注意事项

• 主主复制的两个数据库不能并发写入

• 复制只是增加了数据的读并发处理能力，没有增加写并发能力和存储能力

• 更新表结构会导致巨大的同步延迟

• 数据分片

• 分片目标

• 分片特点

• 分片原理

• 硬编码实现数据分片

• 应用代码将分片key映射成服务器编号

• 映射表外部存储

• 数据分片的挑战

• 需要大量的额外代码，处理逻辑因此变得更加复杂

• 无法执行多分片的联合查询

• 无法使用数据库的事务

• 随着数据的增长，如何增加更多的服务器

• 分布式数据库中间件

• Mycat

• Amoeba/Cobar架构

• Cobar系统组件模型

• 路由配置实例

• Cobar如何做集群的伸缩

• 实践中Cobar扩容策略

• 数据库部署方案

• 单一服务与单一数据库

• 主从复制实现伸缩

• 两个Web服务及两个数据库

• 功能分割

• 以上方案综合部署

NoSQL

• CAP原理

• C一致性

• 每次读取的数据都应该是最近写入的数据或者返回一个错误，而不是过期数据

• A可用性

• 每次请求都应该得到一个响应，而不是返回一个错误或者失去响应

• 不过这个响应不需要保证数据是最近写入的

• 要求系统一直是可以正常运行的，不保证响应的数据是最新的

• P分区耐受性

• 因为网络原因，部分服务器节点之间消息丢失或延迟了，系统依然应该是可以操作的



• 对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证的，那么在可用性和一致性上就必须二选一

• 若选择一致性，系统可能返回一个错误码或者干脆超时，即系统不可用

• 若选择可用性，系统总是返回一个数据，但是并不能保证这个数据是最新的



• 在分布式系统必须要满足分区耐受性的前提下，可用性和一致性无法同时满足

• CAP原理与数据存储冲突



• 最终一致性

• 最终一致写冲突

• 简单冲突处理策略

• 根据时间戳，最后写入覆盖

• 客户端冲突解决

• 合并各个响应结果

• 投票解决冲突Cassandra

• 尝试写入三个节点，至少2个节点响应才更新成功

• 尝试从三个节点读取，至少2个节点返回，取最新版本

• Cassandra分布式解决方案

• HBase架构



• Log Structed Merge Tree

ZooKeeper

• 分布式系统脑裂

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

• 数据库主主备份



• 分布式一致性算法

• Proposer

• Acceptor

• Leaner

• 第一阶段：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请求后

• 不再接受Proposal ID 小于等于 当前请求的Prepare请求

• 不再接受Proposal ID 小于 当前请求的Propose请求

• Zookeeper架构

• Zab协议



• Zookeeper的树状记录结构

• /

• services

• YaView

• servers

• stupidname

• morestupidity

• Locks

• read-1

• apps

• users

• Zookeeper API

String create(path, data, acl, flags)
  
void delete(path, expectedVersion)
  
Stat setData(path, data, expectedVersion)
  
(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

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

Doris——海量KV Engine

• 当前现状

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

• **站UDAS使用

• 存在问题：

• 扩容困难

• 写性能较低

• 实时性低

• 网站有多套KV方案，接口不统一，运维成本高

• 飞天KV Engine（Aspara）问题

• 使用复杂

• 性能较低

• 产品需求

• 定位

• 海量分布式透明化KV存储引擎

• 解决问题

• 替换UDAS

• 关键技术点

• 可用性关键场景

• 瞬时失效

• 瞬时故障是一种严重性较低的故障，一般系统经过较短暂的时间即可自行恢复，遇到瞬时故障，只需要经过多次重试，就可以重新连接到服务器，正常访问

• 临时失效

• 如果应用多次重试后，仍然失败，那么有可能不是瞬时故障，而是更严重的临时故障，这时候需要请求管理中心服务器进行故障仲裁，以判定故障种类，判断为临时故障后执行临时故障处理策略。

• 临时故障要比瞬时故障严重，系统需要人工干预才能恢复正常，在故障服务器未能恢复正常前，系统也必须保证高可用。

• 由于数据有多份拷贝，因此读数据的时候只需要路由选择正常服务的机器即可；

• 写数据的时候，正常服务的机器依然正常写入，发生故障的机器需要将数据写入到临时存储服务器，等待故障服务器恢复正常后再将临时服务器中的数据迁移到该机器，整个集群就恢复正常了。

• 永久失效

• 永久故障是指服务器上的数据永久丢失，不能恢复。

• 由于故障服务器上的数据永久丢失，从临时服务器迁移数据就没有意义，必须要从其他序列中正常的服务器中拷贝全部数据才能恢复正常状态。

• 永久故障发生期间

• 由于系统无法判断该故障时临时故障还是永久故障，因此系统访问结构和临时故障一样。当系统出现临时故障超时（超过设定时间临时故障服务器仍旧没有启动）或者人工确认为永久故障，系统启用备用服务器替代原来永久失效的服务器，进入永久故障恢复，访问模型如图11.9 所示。