CAP定理

CAP定理起源于柏克莱加州大学（University of California, Berkeley）的计算机科学家埃里克·布鲁尔在2000年的分布式计算原则研讨会（Symposium on Principles of Distributed Computing（PODC））上提出的一个猜想。 在2002年，麻省理工学院（MIT）的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为一个定理。很多书籍与文章引用Robert Greiner在2014年8月写的一篇博文 来描述CAP定理，因此就基于Robert Greiner的解释来理解CAP定理



解释

原文：In a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance - one of them must be sacrificed.



翻译：在一个分布式计算系统中，当涉及读写操作时，只能保证一致性、可用性、分区容错性三者中的两个，另外一个必须被牺牲。



这个解释有两个关键点：

1. CAP定理关注的对象是分布式系统中的互联且存在数据共享的

2. CAP定理关注的是数据的读写操作，不是所有功能



一致性(Consistency)

A read is guaranteed to return the most recent write for a given client.

对于某个特定的客户端来说，读操作保证能返回最新的写操作结果。



可用性(Availability)

A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).

非故障节点将在合理的时间内返回合理的响应（不是错误或超时）



分区容忍性(Partition Tolerance)

The system will continue to function when network partitions occur.

当网络分区发生时，系统将继续履行职责



在分布式环境下，网络本身无法做到100%可靠，因此分区是一个必然的现象，分区容忍性是必选项。所以分布式系统只能选择CP架构或者AP架构



从便于理解的角度上可以这么看CAP



实际上的CAP应该是



CP架构



为了保证一致性，当发生分区现象之后，Node 1上的数据由A更新成B，但是由于Node 1和Node 2直接的数据复制通道中断，当前Node 2上的数据还是A，Client访问Node 2的时候返回Error，这违背了可用性，因此当前是CP架构



AP架构



为了保证可用性，当发生分区现象之后，Node 1上的数据由A更新成B，但是由于Node 1和Node 2直接的数据复制通道中断，当前Node 2上的数据还是A，Client访问Node 2的时候返回数据A，这个时候违背了一致性，因此当前架构为AP架构



关注CAP的细节

• CAP关注的关注点是数据，整个定理是基于数据进行讨论的

• CAP是忽略网络延迟的

• 不存在分区时也可以满足CA架构

• 放弃某项的同时一定需要考虑分区恢复之后的操作



BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）



基本可用

分布式系统在出现不可预知故障的时候，允许损失部分可用性，保障核心可用。



软状态

指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。



最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态



BASE理论本质上是对CAP中的AP架构的一个补充。



Doris 故障恢复流程

正常流程

正常情况下读操作是随机从两个分组中选取一个进行的，写操作是并行同时写两个分组。



瞬时故障

当出现瞬时故障的时候客户端会进行重试操作，重试三次



临时故障

当客户端重试三次都没有成功之后进入临时故障处理流程，客户端会通知config服务器，请求故障确认，config服务器会对节点服务进行故障确认操作，如果确认目标节点确实故障了，则通知client将数据写入备用机上，同时屏蔽故障节点的读写请求。当故障节点进行恢复时，故障节点只读不写，备用机将数据拷贝到故障节点进行数据恢复，等数据恢复完成之后再恢复故障节点的写操作。



永久故障

如果故障节点无法恢复，那么故障就升级为永久故障了，这时候有一个时间判断，超过这个时间就停止备用机的写操作。另外一种就是将备用机升级为正式节点以填补永久故障节点