[软件工程] CAP理论和BASE理论

🍁简介

我们在微服务架构设计时候, 通常需要权衡服务以及业务之间的,高可用/一致性/容错性等等问题,

CAP是一个已经经过证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

🍁 一: CAP理论

CAP是 一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）的首字母缩写

🚀1.1 一致性（Consistency）

分布式环境中的一致性是指数据在多个副本之间是否能够保持一致的特性。多个节点副本，如果一个节点进行了更新操作，另一个节点没有得到相应的更新，这时候读取第二个节点数据依然是更新前的数据,也就是我们说的脏数据，这就是分布式节点产生的数据不一致的情况。
如果更新一项数据，所有用户和节点都能读取到最新的值，那么这样的系统就被认为具有强一致性(或严格的一致性)

🚀1.2 可用性（Availability）

可用性表示对请求在有限的时间内返回结果，如果超过了这个时间范围，那么系统就认为是不可用的。两个指标：一个是有限时间（通常搜索引擎是0.5S返回结果），另外一个是业务服务返回结果。如果是系统错误比如：NPE或者“OutOfMemory”等报错信息，则任务系统是不可用的。

🚀1.3 分区容错性（Partition tolerance）

分部署系统节点网络都有相应的数据分区(分布在不同节点)，如果一个节点/分区挂了，那么该节点的数据就访问不到了，比如: 订单服务挂了,所有的用户查看不了订单了,这种没有副本备份造成“功能缺失”的现象，就是丧失了分区容错，这时分区就是无法容忍的。

• 解决方案：
  解决方案就是数据复制到多节点，出现分区之后，这一数据仍然能在其他区中读取，容忍性就提高了。然而复制到多节点就会带来一致性（Consistency）问题,就是多个节点的数据可能是不一致的，要保证一致，就是每次写操作都要等待全部节点写入成功，这种等待就会导致可用性(Availability) 问题 .

🚀1.4 结论

CAP中的C(一致性) 是比较难处理的问题, 追求一致性(强一致性) 会导致服务模块间的耦合性高,那么就会降低可用性（Availability）,所以一致性和可用性存在矛盾,所以CA不能同时满足，只能取得相对的平衡。针对一致性问题,我们延申出BASE理论：
既是：BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。

❗❗ 对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C。

🍁二: BASE理论

主要探讨 是即使无法做到强一致性（CAP的一致性就是强一致性）下面的一致性讨论: BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）首字母缩写。

🚀2.1 基本可用（Basically Available）

基本面临的状况是响应时间较长, 超时降级页面等等状况

🚀2.2 软状态（ Soft State）

典型的副本同步延时就是软状态的体现。mysql replication的异步复制也是一种体现

🚀2.3 最终一致性（ Eventual Consistency）

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

🍁 参考资料 & 致谢

[1] 如何平衡存储系统的一致性和可用性？
[2] CAP和BASE理论