week 6 总结 分布式数据库,CAP,zookeeper

用户头像
a晖
关注
发布于: 2020 年 07 月 15 日

一,分布式数据库

1,Mysql 复制



  • MySQL 主从复制

2,一主多从



2,数据分片

当数量量太大不能放在一个数据库的时候,就需要数据分片。



  • 分片目标

  • 分片特点

  • 分片原理



3,硬编码实现数据分片

4,映射表外部存储

5,数据分片的挑战

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

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

  • 无法使用数据库事务。

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



6,分布式数据库中间件Mycat





7,Amoeba/Cobar架构

8,Cobar 系统组件模型

9,路由配置实例

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE amoeba:rule SYSTEM "rule.dtd">
<amoeba:rule xmlns:amoeba="">
...
<tableRule name="MESSAGE" schema="test" defaultPools="blogdb-1,blogdb-2">
<rule name="rule1">
<parameters>ID</parameters>
<expression><![CDATA[ abs(hash(id)) mod 2 = 0]]></expression>
<defaultPools>blogdb-1</defaultPools>
</rule>
<rule name="rule2">
<parameters>ID</parameters>
<expression><![CDATA[ abs(hash(id)) mod 2 = 0]]></expression>
<defaultPools>blogdb-2</defaultPools>
</rule>
</tableRule>
...
</amoeba:rule>

10,Cobar 如何做集群的伸缩

11,实践中 Corba 扩容策略

Schema实际上就是数据库,扩容的时候把Schema迁移到新的数据库。

比如迁移到新MySQL的Schema有:Schema4,Schema8,Schema12.

这样子每个数据库都有3个Schema。



迁移的流程是,先把旧数据库Schema复制到新的数据库,全部复制完后,删除老数据库的Schema,路由配置实例配置修改。



12,数据库部署方案 - 单一服务与单一数据库

13,数据库部署方案 - 主从复制实现伸缩



14,数据库部署方案 -两个 Web 服务及两个数据库



15,数据库部署方案 - 综合部署



二,CAP原理



1,一致性

一致性是说,每次读取的数据都应该是最近写入的数据或者返回一个错误(Every read receives the most recent write or an error),而不是过期数据,也就是说,数据是一致的。



2,可用性

可用性是说,每次请求都应该得到一个响应,而不是返回一个错误或者失去响应,不过这个响应不需要保证数据是最近写入的(Every request receives a (non-error) response, without the guarantee that it contains the most recent write),也就是说系统需要一直都是可以正常使用的,不会引起调用者的异常,但是并不保证响应的数据是最新的。



3,分区耐受性

分区耐受性说,即使因为网络原因,部分数据库节点之间消息丢失或者延迟了,系统依然应该是可以操作的(The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes)。



4,CAP原理

  • 当网络分区失效发生的时候,我们要么取消操作,这样数据就是一致的,但是系统却不可用;要么我们继续写入数据,但是数据的一致性就得不到保证。



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



  • 当网络分区失效,也就是网络不可用的时候,如果选择了一致性,系统就可能返回一个错误码或者干脆超时,及系统不可用。如果选择了可用性,那么系统总是可以返回一个数据,但是并不能保证这个数据是最新的。



所以,关于 CAP 原理,更准确的说法是,在分布式系统必须满足分区耐受性的前提下,可用性和一致性无法同时满足。



5,CAP 原理与数据存储冲突



6,最终一致性



7,最终一致写冲突

简单冲突处理策略:根据时间戳,最后写入覆盖。

有些应用用GPS的时钟,来保证时间戳的准确性。

8,客户端冲突解决

9,投票解决冲突 (Cassandra)

  • 保证路由算法的一致性。需要自行选择,数据存储到哪里。

  • 这些数据库也是个环状,早期的Cassandra也是用的一致性哈希算法实现服务器扩容的。



三,zookeeper

1,分布式脑裂

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



2,数据库主主备份



3,分布式一致性算法



三个角色:

  • proposer

  • Acceptor

  • Leaner



  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请求后

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

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



4,ZooKeeper 架构



5,ZooKeeper 树状记录结构





6,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)



7,配置管理

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

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



8,选 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



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

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)





10,ZooKeeper 性能

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

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

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

11,Zab 协议



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

用户头像

a晖

关注

还未添加个人签名 2018.12.05 加入

还未添加个人简介

评论

发布
暂无评论
week 6 总结  分布式数据库,CAP,zookeeper