CAP理论与BASE理论

CAP(帽子原理)

由于对系统或者数据进行了拆分，我们的系统不再是单机系统，而是分布式系统，针对分布式系统的CAP原理包含如下三个元素。

C：Consistency，一致性。在分布式系统中的所有数据备份，在同一时刻具有同样的值，所有节点在同一时刻读取的数据都是最新的数据副本。

A：Availability，可用性，好的响应性能。完全的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并进行响应。

P：Partition tolerance，分区容忍性。尽管网络上有部分信息丢失，但系统仍然可继续工作。

 

 

BASE理论

指Basically Available（基本可用），Soft-state（软状态/柔性事务），Eventual Consistency（最终一致性）。

是基于CAP定理演示而来，是对CAP中一致性和可用性权衡的结果。核心思想：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。

1.基本可用：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。比如：搜索引擎0.5秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务等。

2.软状态：软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时。

3.最终一致性：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊情况。BASE理论面向的是大型高可用可扩展的分布式系统，通过牺牲强一致性来获得可用性。ACID是传统数据库常用的概念设计，追求强一致性模型。

 

 

 

例子：

案例：支付项目

                            调用支付接口

支付服务---------------------------------------->支付宝

 

流程说明： 支付服务调用支付宝支付接口，支付宝完成支付逻辑后，调用支付服务的异步回调地址，通知支付结果，支付服务收到支付结果后，执行逻辑之后发送一个确认码给支付宝通知已经收到了。

当支付服务出现异常的情况，导致接收不到支付宝的支付结果通知时，此时支付服务的状态是支付未成功，支付宝的状态是支付已成功，两者的数据是暂时不一致的。此时支付宝会进行补偿机制，每隔几秒钟就访问一次支付服务的异步回调地址，一般会访问三次，三次之后就会每隔很长的一段时间访问一次；当支付服务恢复正常，接收到了支付宝的通知后，就会对数据进行更新，此时支付服务和支付宝的数据状态就变成一致了。这就是最终一致。

 

这种处理方法可以跨语言跨平台，但是比较麻烦，一般用于外部接口或跨语言跨平台，微服务内部不会使用这种方式。