架构师训练营第六章总结

发布于: 2020 年 07 月 15 日

分布式数据库与NOSQL

存储模型

CAP理论

https://xie.infoq.cn/article/1954e2aa291dcd8d81b651073

BASE理论

Basically Available(基本可用),Soft State(软状态)和Eventually Consistent(最终一致性)三个短语的缩写

基本可用(Basically Available)

出现了不可预知的故障,但还是能用,相比较正常的系统而言:1.响应时间损失 2.功能损失

软状态(Soft State)

相对于原子性而言,要求多个节点的数据副本都是一致的,这是一种“硬状态”

允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时

最终一致性(Eventually Consistent)

上面说软状态,然后不可能一直是软状态,必须有个时间期限。在期限过后,应当保证所有副本保持数据一致性,从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素

ACID强一致性模型

关系型数据库

原子性

一致性

隔离性

持久性

ZooKeeper与Doris

zookeeper原理

Zookeeper的核心是原子广播,这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是恢复模式和广播模式。

  当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数server的完成了和leader的状态同步以后,恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态

一旦leader已经和多数的follower进行了状态同步后,他就可以开始广播消息了,即进入广播状态。这时候当一个server加入zookeeper服务中,它会在恢复模式下启动,发现leader,并和leader进行状态同步。待到同步结束,它也参与消息广播。Zookeeper服务一直维持在Broadcast状态,直到leader崩溃了或者leader失去了大部分的followers支持。

广播模式需要保证proposal被按顺序处理,因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64为的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch。低32位是个递增计数。

当leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式需要重新选举出一个新的leader,让所有的server都恢复到一个正确的状态。 

   每个Server启动以后都询问其它的Server它要投票给谁。

   对于其他server的询问,server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid(系统启动时每个server都会推荐自己)

收到所有Server回复以后,就计算出zxid最大的哪个Server,并将这个Server相关信息设置成下一次要投票的Server。

  » 计算这过程中获得票数最多的的sever为获胜者,如果获胜者的票数超过半数,则改server被选为leader。否则,继续这个过程,直到leader被选举出来  

  » leader就会开始等待server连接

  » Follower连接leader,将最大的zxid发送给leader

  » Leader根据follower的zxid确定同步点

  » 完成同步后通知follower 已经成为uptodate状态

  » Follower收到uptodate消息后,又可以重新接受client的请求进行服务了

Doris

分布式存储系统的高可用架构

瞬时故障

临时故障

永久故障

用户头像

吴吴

关注

还未添加个人签名 2018.03.02 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第六章总结