CAP定理

最近发生了比较多的大事情

很遗憾，之前的测试小姐姐被组织给分配走了，以后就是别人的测试小姐姐了

最近成功忽悠到某个开发小姐姐一起写文档，所以新的文档都会先在github上合作开发，等到定稿之后再发布出来

附：原文链接

1. CAP定理

一个分布式系统不可能同事满足一致性(Consistency),可用性(Availability)和分区容忍性(Partition tolerance),最多只能同时满足两个

一致性：数据在多个副本之间保持一致。这很好理解,你在同一时间从集群的任意一个节点进行读写操作,结果都应该一样

可用性：每一个请求都应该在一定时间内获得明确响应。服务一直可以对请求返回相应，而且是正常响应时间

分区容忍性：大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败，失败的情况下仍然能够提供服务。

2. 可用性（Availability）

可用性有两个指标

明确响应：所有可能的响应结果都应该在契约中有明确定义，不应该出现协议之外的响应或异常

一定时间：所有的请求都应该在一定时间内返回，不能让请求方一直等待

对于一个本地调用来说，请求结果通常只有两种状态：成功和失败。但是引入了网络之后，除了成功和失败之外，还会产生超时，这时候是无法确定请求到底是成功还是失败的。

3. 分区容忍性（Partition tolerance）

3.1 分区

首先分区如何产生？因为网络、硬件或软件的原因，导致两个节点之间的消息不能正常投递。那么不能被正常访问到的节点和其它节点就形成了不同的分区。
比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

3.2 分布式系统为什么不能同时选择CA

基于网络的不可靠性，分区必然是会发生的。当分区发生的时候，你或者失去一致性（因为允许分别更新分区两边）或者失去可用性（因为你检测到错误，关闭系统，直到分区消失）
如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。

4. 一致性（Consistency）

4.1 ACID

一致性要求我们在同一时间在系统任何一个节点进行的读写操作都能得到一致的结果。关系型数据库通常会谈到ACID特性，满足ACID特性的数据库都通过事务机制来达到一致性

A: Atomicity，原子性

C : Consistency，一致性

I: Isolation，隔离性。

D: Durability，持久性。

4.2 为什么不一致

分布式系统为了解决大数据、高并发、复杂业务逻辑的问题，会对服务进行水平扩展或垂直拆分

水平扩展：将一个节点扩展为多个节点，那么这些节点之间的数据就可能会产生不一致

垂直拆分：将一个业务拆分成多个职责单一的模块进行合作，那么这些模块之间的数据和状态也就有可能产生不一致

我们仍然可以通过分布式事务来尽量保证一致性，但那将会付出更大的代价

5. BASE理论

在分区容忍性这一节已经分析过了，分区是不可避免的，所以我们需要在C和A之间进行取舍，当然这种取舍也并不是非此即彼的，我们可以在这两者之间找到一个平衡

BASE理论

BA: Basically Available，基本可用。基本可用是指在出现故障时，可以损失一部分非核心流程的可用性来保证系统基本可用

S: Soft State，软状态。允许状态在一段时间内不同步。

E: Eventually Consistent，最终一致。你不能让系统永远处于软状态，所以在一定的时间窗口内，最终数据达成一致即可。

BASE理论是在CAP定理下在一致性和可用性之间进行博弈的结果。不要求强一致性，而是根据自身的业务特点，采用适当的方式来使系统达到最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

事实上，最终一致性并不是只有那些大型分布式系统才设计的特性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。在同步方式中，数据的复制通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么显然，从备库中读取的的数据将是旧的，因此就出现了不一致的情况。当然，无论是采用多次重试还是认为数据订正，关系型数据库还是能搞保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。

TIPS

什么是4个9

系统可用性=系统可用时间/（系统可用时间+系统故障时间）比如说你有一个系统，在过去一年里总共有24小时的时间因为各种故障导致不能对外提供服务，那么可用性就是364/365=99.73% emmm...这就叫两个9

通俗叫法	可用性级别	年度停机时间
2个9	99%	87.6小时
3个9	99.9%	8.8小时
4个9	99.99%	53分钟
5个9	99.999%	5分钟

参考

《分布式服务架构：原理、设计与实战》一书作者李艳鹏、杨彪，电子工业出版社2017年8月出版》
CAP迷思：关于分区容忍性