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

关注

发布于: 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也是用的一致性哈希算法实现服务器扩容的。
﻿
三，zookeeper1，分布式脑裂在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个集群陷入混乱，数据损坏，称为分布式脑裂。
﻿
2，数据库主主备份
﻿
3，分布式一致性算法﻿
三个角色：
 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请求后
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:
Watch on/nodes
On watch trigger do getChildren(/nodes, true)
Track which nodes have gone away
﻿
Each Node:
Create /nodes/node-${i} as ephemeral nodes
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最大的服务器。