基本理论

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小时内恢复的时候。临时失效节点会从备份节点同步失效这段时间的操作，同时接受客户端的写操作，直到数据恢复到和正常节点一致的状态。