cap 原理总结 &doris 的失效处理过程

发布于: 2020 年 07 月 13 日

基本理论

cap理论是对分布式系统的特性抽象。

它将分布式系统的特性抽象为:一致性、可用性和分区容错性。

 

一致性C:客户端每次读操作,不管访问系统中的那一个节点,要么读到最新的数据,要么读取失败。一致性强调数据的正确性。

可用性A:客户端的每次读操作,系统都保证给与响应,但不保证返回的是最新的数据。可用性强调的是系统的服务可用。

分区容错性P:当系统内节点间出现任意数量的消息丢失或高延迟的时候,系统仍然可以对外提供服务。分区容错性在分布式系统中是必然的,因为网络天然具有不稳定性。

CAP不能同时保证

因为分布式系统时基于网络的,只要是网络交互,就一定会存在延迟和消息丢失,那么分布式系统的分区容错性是必须保证的。

在分区容错性必须保证的前提下。

如果要保证一致性,那么当系统出现了网络不通的时候,系统就无法对外提供服务,因为节点间信息不通,无法保证数据绝对一致。

如果要保证可用性,那么当系统出现了网络不通的时候,数据更新就可能因为网络不通而无法到达所有节点,导致节点提供的数据不是最新的。

举例

我们有一个分布式系统,如下图

网络没有发生故障的时候,server1是主节点。当client1向server1写入数据的时候,server1将数据同步到server2,只有server2响应成功之后,server1才会向client1返回成功的响应。

这个时候client2不论是去server1还是向server2读取,都是读到的最新数据。

但是之前提到了,在分布式系统中网络故障、延迟是不可避免的。

保证可用性时,网络不通可能是server1掉线,也可能是server1到server2的网路中断。

当出现网络故障时,server1收到client1的写入请求,但是无法将数据及时通知到server2。如果要保证系统的可用性,此时client2向server2读取将得不到数据1,而向server1读取却能得到数据1。

那么如果是保证一致性,那么遇到网络分区的情况时,系统中的节点会拒绝向客户端提供服务,直到网络恢复。

保证一致性时

现实中cap的例子

我们常用的zookeeper是采用了cp原则。

具体表现为,如果系统中的leader掉线后,那么系统会立即进入leader选举,整个选举的时间段内,系统是不对外提供服务的,不满足可用性。

服务注册系统consul也是基于cp原则,当leader挂掉时,系统选主的过程中,整个系统也是出于不可用装填。

同为服务注册系统的eureka则是基于ca原则,当leader挂掉的时候,系统依然对外提供服务,但是可能得到的数据不是最新的。

doris的失效处理

判断系统进入临时失效状态

当客户端向dataserver节点发送请求时,如果三次重试dataserver都失败,那么客户端会配置管理中心提交dataserver失效的报告。配置管理中心会想dataserver发送最多三次心跳检测,如果三次检测也失败,那么认为dataserver进入失效状态。

临时失效中的读写过程

进入临时失效状态的dataserver不接收客户端的请求。客户端会此时对正常的节点进行正常的读写操作,同时对集群中的备份节点做写操作,集群中的备份节点会记录操作的日志,以便后续恢复。

失效恢复过程

当临时失效节点在2小时内恢复的时候。临时失效节点会从备份节点同步失效这段时间的操作,同时接受客户端的写操作,直到数据恢复到和正常节点一致的状态。

用户头像

而立

关注

还未添加个人签名 2018.01.25 加入

还未添加个人简介

评论

发布
暂无评论
cap原理总结&doris的失效处理过程