简单来说：
BASE（Basically Available、Soft state、Eventual consistency）是基于CAP理论逐步演化而来的，核心思想是即便不能达到强一致性（Strong consistency），也可以根据应用特点采用适当的方式来达到最终一致性（Eventual consistency）的效果。
BA基本可用，就是一种妥协，在节点故障或系统过载，通过牺牲非核心功能可用性，保障核心功能的稳定运行。（流量削峰，延迟响应异步处理，体验降级，过载保护熔断/限流，故障隔离）
S软状态，允许系统中的数据存在中间状态，允许系统存在数据延迟
E最终一致性，不能一直处于软状态，一定时间期限后，保证所有副本一致性
- 有点BA对应AP，S对应P，E对应CP意味
1. 理论内容
BASE 理论是对 CAP 理论的一种延伸和补充，它是基于 Basically Available（基本可用）、Soft state（软状态）和 Eventually Consistent（最终一致性）这三个特性来描述分布式系统的。
-
基本可用：意味着系统在出现故障或者高负载等异常情况下，虽然不能像正常情况那样提供完整的服务，但仍然能够提供部分服务，以满足用户的基本需求。就是不断妥协一些方面来保证基本可用。例如，在电商大促期间，由于订单量暴增，系统可能会限制某些非关键功能的使用，如商品评论功能可能会暂时关闭，或者降低图片的分辨率以节省网络资源，这样虽然系统的服务有所缺失，但仍然可以让用户完成基本的购物流程，即实现了基本可用。
-
软状态：指的是系统中的数据存在一种介于已完成和未完成之间的中间状态，这种状态是可以被接受的。比如，在一个分布式存储系统中，当用户上传一份文件时，可能在某个瞬间，系统中的某些节点已经接收到了文件的部分内容，而其他节点还没有接收到，这就是一种软状态。这种状态在系统运行过程中是正常存在的，并且会随着时间的推移逐步趋向于完成状态。
-
最终一致性：表示尽管在系统运行过程中可能会出现数据不一致的情况，但经过一段时间后，系统中的所有数据副本最终会达到一致状态。例如，在一个分布式数据库系统中，不同节点上的数据可能会因为网络分区、并发操作等原因出现不一致，但随着网络分区的恢复、并发操作的完成等，经过一定的时间，所有节点上的数据最终会变得一致。
2. 设计理念
BASE 理论的设计理念是接受分布式系统中存在的不确定性和不完善性，不强求在任何时刻都保持数据的一致性，而是通过允许系统存在软状态和最终实现一致性的方式，来提高系统的灵活性和可用性。它与 CAP 理论中的 AP 系统有一定的相似性，都是在一定程度上放弃了严格的一致性要求，但 BASE 理论更强调系统在面对各种复杂情况时如何通过自身的调整和发展来实现最终的一致性，而不是简单地放弃一致性。
区别总结
-
特性描述：
-
CAP 理论主要关注的是一致性、可用性和分区容错性这三个关键特性，并且指出在分布式系统中这三个特性之间存在着不可调和的矛盾，必须在三者之间进行权衡取舍。
-
BASE 理论则围绕基本可用、软状态和最终一致性这三个特性来描述分布式系统，它是对分布式系统在实际运行过程中可能出现的各种情况的一种描述，强调系统可以存在软状态并通过自身的发展来实现最终一致性。
-
-
设计理念：
-
CAP 理论的设计理念是基于对分布式系统特性的严格定义和权衡取舍，根据不同的应用场景选择放弃其中一个特性来满足其他两个特性。
-
BASE 理论的设计理念是接受分布式系统中的不确定性和不完善性，通过允许系统存在软状态和最终一致性的方式来提高系统的灵活性和可用性，而不是像 CAP 理论那样进行严格的权衡取舍。
-
-
应用场景：
-
CAP 理论在选择设计方案时，更适合用于对数据一致性要求非常高的系统（如金融交易系统）或者对可用性要求非常高的系统（如社交网络系统）等，根据具体需求选择 CP 或 AP 方案。
-
BASE 理论更适合用于那些在运行过程中可能会出现各种复杂情况（如高负载、网络分区等）的分布式系统，如电商平台、内容分发系统等，通过实现基本可用、软状态和最终一致性来应对这些复杂情况。
-
综上所述，CAP 理论和 BASE 理论从不同的角度对分布式系统进行了描述和分析，它们在特性描述、设计理念和应用场景等方面存在着明显的区别，在实际的分布式系统设计和开发中，需要根据具体的需求和情况选择合适的理论作为指导。
再理解
BASE（Basically Available、Soft state、Eventual consistency）是基于CAP理论逐步演化而来的，核心思想是即便不能达到强一致性（Strong consistency），也可以根据应用特点采用适当的方式来达到最终一致性（Eventual consistency）的效果。
(1) BASE的主要含义：
BASE是Basically Available(基本可用）、**Soft state(软状态）和Eventually consistent(最终一致性）**三个短语的简写。
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方法来使系统达到最终一致性。
两个对冲理念：ACID和BASE
ACID是传统数据库常用的设计理念，追求强一致性模型。
BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。
(2) Basically Available(基本可用)
基本可用本质是一种妥协，也就是出现节点故障或者系统过载时，通过牺牲非核心功能的可用性，保障核心功能的稳定运行。
实现基本可用的几个策略：
1、流量削峰（不同地区售票时间错峰出售）
以订票系统设计为例，在春运期间，开始售票前后会出现及其海量的请求峰值。
可以在不同的时间，出售不同区域的票，将访问请求错开，削弱请求峰值。
2、延迟响应，异步处理（买票排队，基于队列先收到用户买票请求，排队异步处理，延迟响应）
还以订票系统为例。用户提交购票请求后，往往会在队列中排队等待处理，可能几分钟或十几分钟后，系统才开始处理，然后响应处理结果。
3、体验降级（看到非实时数据，采用缓存数据提供服务）
以互联网系统为例，若出现网络热点事件，产生了海量的突发流量，系统过载，大量图片因为网络超时无法显示，那么可以用小图片代替原始图片，降低图片的清晰度和大小，提升系统处理能力。
4、过载保护熔断/限流，直接拒绝掉一部分请求，或者当请求队列满了，移除一部分请求，保证整体系统可用）
把接收到的请求放在指定的队列中排队处理，如果请求等待时间超时，这时直接拒绝超时请求；如果队列满了之后，就清除队列中一定数量的排队请求，保护系统不过载，实现系统基本可用。
5、 故障隔离（出现故障，做到故障隔离，避免影响其他服务）
(3) Soft state（软状态）
原子性（硬状态） -> 要求多个节点的数据副本都是一致的,这是一种"硬状态"
软状态（弱状态） -> 允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟。
(4) Eventually consistent（最终一致性）
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。
稍微官方一点的说法就是：
系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。
(5) BASE总结
总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。
参考：图灵课堂