ZooKeeper
2020-12-18 18:42:10 0 举报
AI智能生成
登录查看完整内容
zookeeper
作者其他创作
大纲/内容
ZooKeeper
分布式发展流程
分布式特点
分布式
对等性
并发性
缺乏全局时钟
ACID到CAP/BASE
单机事务
原子性 Atomicity
一致性 Consistency
隔离性 Isolation
Read Uncommitted 读未提交
允许脏读
可重复读
幻读
Read Commited 读以提交
Repeatable Read 可重复读
幻读(Innodb 目前已经解决了这个问题 使用的MVCC 和Lock)
Serializable 串行化
持久性 Durability
分布式事务
CAP 定理一个分布式系统不可能同时满足一致性(C: Consistency)、可用性(A: Availability)和分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中的两项
一致性
指数据在多个副本之间是否能够保持一致的特性
可用性
系统提供的服务必须一直处于可用状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果
分区容错性
分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非整个网络环境都发生故障
Base 理论是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写
Basically Available(基本可用)
响应时间上的损失
功能上的损失
Soft state(软状态)
允许系统中存在中间态数据 ,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
Eventually consistent(最终一致性)
系统数据经过一段时间的同步后,最终能够达到一个一致的状态
选举
leader启动选举
leader崩溃选举
一致性协议
2PC
Two-Phase Commit 即二阶段提交
提交事务请求
事务询问
执行事务
各参与者节点执行事务操作,并将Undo和Redo消息记入事务日志中
各参与者向协调者反馈事务询问的响应
执行事务提交
发送提交请求
事务提交
反馈事务提交结果
完成事务提交之后,想协调者发送Ack消息
完成事务
协调者接收到所有参与者反馈的Ack消息后,完成事务
中断事务
发送回滚事务
事务回滚
反馈事务回滚结果
优点
原理简单 ,实现方便
缺点
同步阻塞
单点问题
协调者出现问题。二阶段提交流程无法运转
脑裂
执行事务提交的时候,当协调者向所有的参与者发送Commit请求之后,发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃,导致最终只有部分参与者收到了Commit请求。收到Commit请求的参与者就会进行事务的提交,而其他没有收到Commit请求的参与者则无法进行事务提交,于是整个分布式系统出现了数据不一致性现象
太过保守
3PC
Three-Phase Commit 即三阶段提交
CanCommit
各参与者向协调者返回事务询问的响应
PreCommit
执行事务预提交
发送预提交请求
事务预提交
参与者接收到preCommit请求后,会执行事务操作,并将Undo和Redo信息记录到事务日志中
各参与者向协调者反馈事务执行的响应
如果参与者成功执行了实务操作,那么就会反馈给协调者Ack响应,同时等待最终的指令:提交(Commit)或中止(abort)
发送中断请求
doCommit
执行提交
降低了参与者的阻塞范围,并且能够在出现单点故障后继续达成一致
参与者接收到preCommit消息后,如果网络出现分区,此时协调者所在的节点和参与者无法进行正常的网络通信,在这种情况下,该参与者依然会进行事务的提交,这必然出现数据的不一致性
选举协议
Paxos算法
Google Chubby 中使用的算法
ZAB协议
崩溃恢复
就是lead选举的过程
消息广播
已经处理的消息不能丢失(zxid)
被丢弃的消息不会再出现
集群角色
Leader角色
食物请求唯一调度和处理者,保证集群事务处理的顺序性,集群内部各服务器的调度者
Follower 角色
处理非事务请求,参与事务请求Proposal的投票 参与leader选举投票
Observer 角色
观察者角色 不参与投票
0 条评论
回复 删除
下一页