CAP介绍

CAP原则又称CAP定理：

一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。

这里是 强一致性，所有节点在同一时间具有相同的数据

一般互联网产品不要求强一致性，如：发微博、朋友圈、抖音，粉丝并不会立刻看到

一般传统xx管理系统要求强一致性，如：银行转账成功后，必须能查到金额

保证每个请求不管成功或者失败都有响应，且不会出现响应超时或响应错误

一般互联网产品要求高可用性，如：发微博、朋友圈、抖音，要及时响应结果（提示发送失败也是响应结果），不能崩溃报错

一般传统xx管理系统不要求高可用性

通常分布式系统的各节点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致结点之间通信失败，此时仍可以对外提供服务

一个 分布式 系统只能 同时实现两点，不可能三者兼顾。

满足一致性，可用性的系统，不进行分区，也就不是标准的分布式系统

传统web管理系统、个人博客、关系型数据库

满足一致性，分区容忍性的系统，通常性能不是特别高

一般分布式NoSQL数据库采用CP、分布式web管理系统

满足可用性，分区容错性的系统，通常可能对一致性要求低一些。

一般互联网产品采用AP。

在访问高峰期时，实际的点赞量，与看到的点赞量，不一致时，是可以接受的，但应用不能报错！过了访问高峰期，数据保持一致就可以。

BASE介绍

BASE理论是对 CAP理论的延伸，AP 在实际应用中较多，AP 舍弃一致性，保证可用性和分区容忍性，但是在实际使用中都要实现一致性，这就产生了矛盾

BASE是指：

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性），允许损失部分可用性。需要注意的是，基本可用绝不等价于系统不可用。

响应时间上的损失：正常情况下搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

注意： 与CAP中的强一致性不同，其要求在任何时间查询每个结点数据都必须一致

基于以上，一般互联网产品采用 AP+BASE 较多