在学习Spring Cloud注册中心时,了解到了CAP这个知识点,个人对这类理论知识兴趣浓厚,特别是和之后要学习强相关的,遂边学习边记录一波
在开始之前,我们先从一个案例入手
如上图,单机系统下,有一个售票处1,n个用户去买票,在排除并发安全等相关情况后,这个系统可以正常工作,一段时间后,因为用户逐渐增加,一个服务器承受不住了,于是增加了一个售票处2
这里开始就涉及到分布式相关知识了,就像我们上面说的,一个服务器、数据库干不动了,就给他再来一个,他们做一样的事,但是他们用的应该是同一个数据源(库存),当其中一个售票处卖出了票,他们本地的数据库(库存数量)更新了,他就要想办法让其他售票处知道最新的库存,这就涉及到分布式系统的沟通交流协作问题,就来到了我们想说的CAP理论。
说到分布式,我第一个了解到的就是CAP理论
2000 年的时候,Eric Brewer 教授提出了 CAP 猜想,这个猜想首次把一致性、可用性和分区容错三个因素提炼出来作为系统设计的重要特征,断言用此三者可以划分所有的分布式系统,并指明这三个特征之间的不可能性关系。
2002年,Lynch与其他人证明了Brewer猜想,并上升为定理,但是,她只是证明了CAP三者不可能同时满足,并没有证明任意二者都可满足的问题,所以,该证明被认为是一个收窄的结果。
这时的CAP没有考虑不同的基础架构、不同的应用场景、不同的网络基础和用户需求,而C、A、P在这些不同场景中的含义可能完全不同,这种无视差异化的定义导致了非常大的概念模糊,就引来了诸多质疑.
面对大量的质疑,Brewer和Lynch终于坐不住了,Brewer于2012年进行了重申,Lynch也在2012年重写了论文,缩小CAP适用的定义,消除质疑的场景;展示了CAP在非单一一致性结果下的广阔的研究结果.并顺便暗示CAP定理依旧正确!
经过长久的发展就是现在,我们能看到的, 并有了以下的定义
选项 | 描述 |
---|---|
C(Consistence) | 一致性,指数据在多个副本之间能够保持一致的特性(严格的一致性)。 |
A(Availability) | 可用性,指系统提供的服务必须一直处于可用的状态,每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。 |
P(Partition Tolerance) | 分区容错性,分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障。 |
高可用、数据一致是很多系统设计的目标,所以我们只能有这几种选择
关于一致性: 我们都知道,在不同场景下,对一致性的要求是不一样的,有些可以牺牲一致性,但是像银行转账这种,就肯定不行,A给B转账100. 就必须保证A账号扣了100,B的账户多了100.这里强调的就是数据的一致性,而且什么时候转钱都可以,也需要可用性。但是可以转钱失败是可以允许的。
需要注意的是:CAP理论中的CA和数据库事务中ACID的CA并完全是同一回事儿。两者之中的A都是C都是一致性(Consistency)。CAP中的A指的是可用性(Availability),而ACID中的A指的是原子性(Atomicity),切勿混为一谈.
分区和分区容错是两个东西。
分区是一种现象,当系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况。
而分区容错是一个系统的特性,指的是你这个系统对于分区这种现象有多高的容错能力。
-《从PAXOS到ZOOKEEPER分布式一致性原理与实践》
一啊开始说到,我是学习Spring Cloud的注册中心才知道的CAP,这里就放下尚硅谷阳哥的图
引用大佬的话
首先肯定的是,CAP并不适合再作为一个适应任何场景的定理,它的正确性更加适合基于原子读写的NoSQL场景。而无论如何C、A、P这个三个概念始终存在任何分布式系统,只是不同的模型会对其有不同的呈现,可能某些场景对三者之间的关系敏感,而另一些不敏感。
有兴趣的同学可以查看参考资料1, 作者进行了非常详细的讲诉.
1. CAP理论历史
2. [分布式]:分布式系统的CAP理论
1. 分布式理论的协议和相关算法@TOC