1、起源
CAP 定理( CAP theorem )又被称作布鲁尔定理( Brewer’s theorem)，由加州大学伯克利分校的计算机科学家埃里克·布鲁尔在 2000 年的 ACM PODC 上提出的一个猜想。2002 年，麻省理工学院的赛斯·吉尔伯特和南希 ·林奇发表了布鲁尔猜想的证明, 使之成为分布式计算领域公认的一个定理。
2、背景
在分布式系统的设计重点需要解决两个问题：横向扩展和高可用性,横向扩展是为了解决单点性能瓶颈问题，从而保证可用性，高可用是为了解决单点故障问题，进而保障部分节点故障时的可用性，由此可以看到，分布式系统的核心诉求就是可用性。这个可用性正是CAP中的A；用户访问系统时，可以在合理的时间内得到合理的响应。 为了保证可用性，一个分布式系统通常由多个节点组成，这些节点各自维护一份数据，但是不管用户访问哪个节点，原则上都应该读取到相同的数据。为了达到这个效果，一个节点收到写入请求更新自己的数据后，必须将数据同步到其他节点，以保证各个节点的数据一致性，这个一致性正是CAP中的C：用户访问系统时，可以读取到最近写入的数据。 分布式系统中，节点之间数据的同步是基于网络的，由于网络本身的不可靠性，极端情况下会出现网络不可用，从而将网络两端的节点孤立开来，这就是网络分区的现象。发生网络分区时，系统中多个节点数据一定是不一致的，但可以选择对用户表现出一致性，代价是牺牲可用性，将未能同步到新数据的部分节点设置为不可用，当然也可以选择可用性，此时系统中各个节点都是可用的，只是返回给用户的数据不一致，这里的选择，就是CAP中的P。
解释
-
C：一致性C代表更新操作成功后，所有节点在同一时间的数据保持完全一致。
-
A：可以性A代表用户访问数据的时候，系统是否能在正常响应时间返回预期的结果。
-
P：分区容错性P代表分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
CAP定理在系统的实际开发和使用中不可能同时都满足的。
如在同一个电商系统，分为了两个系统，分别为订单系统和库存系统，当用户下单的时候，首先，会先创建一个订单，然后去减少库存系统中的商品库存，因为两个系统运行在不同的服务器下，中间又由网络连接，会出现数据一致性的问题。主要解决方案我们可以参考CAP定理根据实际的需求来解决。
CP（强一致性）：CP的主要表现为订单创建成功后，一直处于等待的状态，库存减少成功后才会返回结果。缺点用户体验比较差，如果没有处理成功就会一直处于等待的状态，优点可以保证数据的强一致性。
AP：AP表现为订单创建成功后，不等待库存减少直接返回处理结果。保证可用性，牺牲掉了数据的一致性，这里减库存的操作是通过异步的方式进行的，所以基于AP的模式，我们创建订单成功后就会直接返回结果，而不会在乎库存是否减少成功，这里产生最大的问题就是可能会导致数据的不一致性。
AC：表现为不拆为数据系统，在一个数据库的一个事务中完成所有的操作，这个就是单体应用的体现
扩展：BASE理论
为了解决CAP限制，出现了BASE理论，也就是基本可用（Basically Available）、软状态（Soft state）、最终一致性（Eventually Consistent）理论。BASE是对CAP中一致性和可用性权衡的结果，其通过牺牲强一致性来获取高可用性。
1、基本可用（Basically Available） ：指的是分布式系统在出现故障的情况下，仍然可以提供服务，尽管这个服务可能不完全，或者有降级，这里的关键是部分和核心。
以电商网站为例，假设一个电商网站有订单服务、商品浏览服务、评论服务、搜索服务等多个服务。如果因为某种原因（如网络分区、硬件故障等）导致评论服务暂时不可用，但是其他服务，如订单服务、商品浏览服务、搜索服务等仍然可用。此时，用户仍然可以浏览商品、下订单和搜索，只是不能进行评论。也就是说，整个系统仍然是"基本可用"的。
2、软状态（Soft state） ：允许系统中的数据存在一段时间的不一致。
例如，当你第一次访问一个网站的时候，你的计算机会向DNS服务器查询这个网站对应的IP地址，然后DNS服务器会返回IP地址，这个IP地址会被你的计算机或者你的网络设备缓存起来，以备下次访问的时候使用，以节省查询时间。但是，如果在这个缓存期间，网站服务器更换了IP地址，那么你的计算机或者网络设备缓存的DNS解析结果就会过期，这就是一个"软状态"。
3、最终一致性（Eventually Consistent） ：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。这里的关键词是“一定时间”和“最终“，“一定时间”和数据的特性是强关联的，不同的数据能够容忍的不一致时间是不同的。
相关技术框架
- Seata：Seata是一个开源的分布式事务解决方案，它提供了多种事务模式，如AT模式、TCC模式、Saga模式等，以支持不同的业务需求。Seata通过全局事务ID来标识一个分布式事务，并协调各个分支事务的执行，以确保数据的一致性和完整性。
- Spring Cloud Distributed Transaction：Spring Cloud提供了一套分布式事务解决方案，它基于Spring框架的特性和优势，可以方便地集成到Spring Cloud应用中。通过Spring Cloud Distributed Transaction，开发者可以轻松地管理分布式事务，确保数据的一致性。
- Narayana：Narayana是另一个流行的分布式事务框架，它遵循JTA/JTS规范，提供了完整的分布式事务处理功能。Narayana支持多种数据库和消息中间件，可以轻松地集成到各种分布式系统中。
- DTM框架: 支持多语言的分布式事务框架，主要解决服务之间的数据一致性问题github.com/yedf/dtm
