Spring Cloud Alibaba 核心理论 CAP与BASE理论简单理解（5）

由于 CAP 和 BASE 理论是关于分布式系统不可绕开的话题，数据一致性，最终一致性，分区容错等，这里就简单的说明下。推荐一篇文章

CAP

首先呢，需要理解的是，CAP 理论是主要是针对于分布式系统而言的。CAP 分别指的是：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

• 一致性（C）： 所有节点都可以访问到最新的数据。在写操作之后的读操作，所有节点能访问的数据都是一致的。（分为弱一致性，强一致性和最终一致性）。
• 可用性（A）： 每个请求都是可以得到响应的，不管请求是成功还是失败。 就是表示任何时候都可以提供服务，数据可以不是最新但是一定要有响应。
• 分区容错性（P）： 除了全部整体网络故障，其他故障都不能导致整个系统不可⽤。

CAP理论

就是说在分布式存储系统中，最多只能实现上⾯的两点。⽽由于当前的⽹络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在⼀致性和可⽤性之间进⾏权衡

• CA： 如果不要求P（不允许分区），则C（强⼀致性）和A（可用性）是可以保证的。但放弃的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署⼦节点，这是违背分布式系统设计的初衷的。

• CP： 如果不要求A（可用），每个请求都需要在服务器之间保持强⼀致，而 P（分区）会导致同步时间⽆限延⻓(也就是等待数据同步完才能正常访问服务)，⼀旦发⽣网络故障或者消息丢失等情况，就要牺牲⽤户的体验，等待所有数据全部⼀致了之后再让⽤户访问系统。

• AP：要⾼可⽤并允许分区，则需放弃⼀致性。⼀旦分区发⽣，节点之间可能会失去联系，为了高可用，每个节点只能⽤本地数据提供服务，而这样会导致全局数据的不⼀致性。

CAP下注册中心

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集成	⽀持	⽀持	⽀持	⽀持

• Zookeeper：CP设计，保证了⼀致性，集群搭建的时候，某个节点失效，则会进⾏举⾏的leader，或者半数以上节点不可⽤，则⽆法提供服务，因此可⽤性没法满⾜。
• Eureka：AP原则，⽆主从节点，⼀个节点挂了，⾃动切换其他节点可以使⽤，去中⼼化

简单的结论

• 分布式系统中 P，肯定要满足，所以只能在CA中⼆选⼀没有最好的选择，最好的选择是根据业务场景来进⾏架构设计
• 如果要求⼀致性，则选择 zookeeper/Nacos，如⾦融⾏业 CP
• 如果要求可⽤性，则 Eureka/Nacos，如电商系统 AP
• CP ： 适合⽀付、交易类，要求数据强⼀致性，宁可业务不可⽤，也不能出现脏数据
• AP： 互联⽹业务，⽐如信息流架构，不要求数据强⼀致，更想要服务可⽤

BASE 理论

什么是 BASE 理论

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理论往往是结合一起使用的。