由于 CAP 和 BASE 理论是关于分布式系统不可绕开的话题,数据一致性,最终一致性,分区容错等,这里就简单的说明下。推荐一篇文章
首先呢,需要理解的是,CAP 理论是主要是针对于分布式系统而言的。CAP 分别指的是:一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。
(分为弱一致性,强一致性和最终一致性)。就是说在分布式存储系统中,最多只能实现上⾯的两点。⽽由于当前的⽹络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在⼀致性和可⽤性之间进⾏权衡

CA: 如果不要求P(不允许分区),则C(强⼀致性)和A(可用性)是可以保证的。但放弃的同时也就意味着放弃了系统的扩展性,也就是分布式节点受限,没办法部署⼦节点,这是违背分布式系统设计的初衷的。
CP: 如果不要求A(可用),每个请求都需要在服务器之间保持强⼀致,而 P(分区)会导致同步时间⽆限延⻓(也就是等待数据同步完才能正常访问服务),⼀旦发⽣网络故障或者消息丢失等情况,就要牺牲⽤户的体验,等待所有数据全部⼀致了之后再让⽤户访问系统。
AP:要⾼可⽤并允许分区,则需放弃⼀致性。⼀旦分区发⽣,节点之间可能会失去联系,为了高可用,每个节点只能⽤本地数据提供服务,而这样会导致全局数据的不⼀致性。
CAP⾥⾯下的注册中⼼选择思考
常⻅注册中⼼:zk、eureka、nacos,那我们应该怎么选择呢?
| Nacos | Eureka | Consul | Zookeeper | |
|---|---|---|---|---|
| ⼀致性协议 | CP+AP | AP | CP | CP |
| 健康检查 | TCP/HTTP/MYSQL/Client Beat | ⼼跳 | TCP/HTTP/gRPC/Cmd | Keep Alive |
| 雪崩保护 | 有 | 有 | ⽆ | ⽆ |
| 访问协议 | HTTP/DNS | HTTP | HTTP/DNS | TCP |
| SpringCloud集成 | ⽀持 | ⽀持 | ⽀持 | ⽀持 |
简单的结论
CAP 中的⼀致性和可⽤性进⾏⼀个权衡的结果,核⼼思想就是:我们⽆法做到强⼀致,但每个应⽤都可以根据⾃身的业务特点,采⽤适当的⽅式来使系统达到最终⼀致性, 来⾃ ebay 的架构师提出。
BASE 理论是 CAP 理论的延伸,即使无法做到强一致性(Strong Consistency),但是应该可以采用适合的方式达到最终一致性(Eventaul Consitency)。
Basically Available(基本可⽤)
Soft state(软状态)
Eventually consistent(最终⼀致性)
**强一致性:**这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往是对系统的性能影响大。强一致性很难实现。
弱一致性: 这种一致性级别约束了系统在写入成功后,不承诺立即可以读取到写入的数据,也不承诺多久后可以达到数据的一致,但是会尽可能的保证某个时间级别(比如秒级别)后数据可以达到最终一致。
读写一致性: 用户读取自己写入结果的一致性,保证用户永远能够第一时间看到自己更新的内容。 比如我们发一条朋友圈,朋友圈的内容是不是第一时间被朋友看见不重要,但是一定要显示在自己的列表上。
因果一致性: 指的是:如果节点 A 在更新完某个数据后通知了节点 B,那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时,和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
单调读一致性: 当前节点读取到数据项之后,那么系统对于当前节点后续读到的数据项不能返回更旧的值。 由于主从节点更新数据的时间不一致,导致用户在不停地刷新的时候,有时候能刷出来,再次刷新之后会发现数据不见 了,再刷新又可能再刷出来,就好像遇见灵异事件一样。
最终一致性: 最终一致性是所有分布式一致性模型当中最弱的。可以认为是没有任何优化的“最”弱一致性,它的意思是说,不考虑所有的中间状态的影响,只保证当没有新的更新之后,经过一段时间之后,最终系统内所有副本的数据是正确的。 它最大程度上保证了系统的并发能力,也因此,在高并发的场景下,它也是使用最广的一致性模型。
总的来说,BASE 理论面向的是大型高可用可扩展的分布式系统,和传统事务的 ACID特性相反,它完全不同于ACID的强一致性模型,而是提出通过牺牲强一致性来获得可用性,并允许数据在一段时间内不一致,但最终达到一致状态。同时,在实际的分布式场景中,不同的业务单元和组件对数据的一致性的要求是不同的,因此在具体的分布式系统架构设计中,ACID特性与BASE理论往往是结合一起使用的。