遇到了分布式事务的场景我们该如何去进行事务控制呢，本节学习如何选型分布式事务的控制方案。
什么是CAP原理
首先需要理解什么是CAP原理，明白了CAP原理有助于我们去选型分布式事务的控制方案。
CAP是 Consistency、Availability、Partition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍性。使用下图去理解CAP：下图表示客户端经过网关访问订单服务，库存服务
一致性: 向系统写一个新数据再次读取到的也一定是这个新数据。拿上图举例，请求订单服务下单，订单服务请求库存服务扣减库存，只要下单成功则库存扣减成功。
可用性：任何时间都可以访问订单服务和库存服务，系统保证可用。
分区容忍性：也叫分区容错性，分布式系统在部署时服务器可能部署在不同的网络分区，比如上图中订单服务在北京，库存服务在上海，由于处于不同的网络分区如果网络通信异常就会导致节点 之间无法通信，当出现由于网络问题导致节点 之间无法通信，此时仍然是对外提供服务的这叫做满足分区容忍性。
CAP理论要强调在分布式系统中C、A、P这三点不能全部满足。
由于是分布式系统就要满足分区容忍性，因为分布式系统难免存在网络分区，不能因为网络异常导致整个系统不可用，所以P是一定要满足的。满足P，那么C和A不能同时满足。拿上图举例说明：
当订单服务与库存服务出现网络通信异常，订单服务无法访问库存服务，此时如果要保证数据一致性则下单接口必须不可用，如果要保证可用性数据将出现不一致。
学习了CAP理论我们知道进行分布式事务控制要在C和A中作出取舍，进行分布式事务控制要么保证CP要么保证AP。具体要根据应用场景进行判断，下边举例说明CP和AP业务场景的例子。
符合CP的场景：满足C舍弃A，强调一致性。
金融系统：一般需要在多个账户之间进行交易或资金转移的操作通常需要满足CP，这是因为在这种场景下，数据的一致性是至关重要的，确保不会发生资金丢失、重复扣款或其他意外情况，源账号和目标账号的转账结果要么都成功要么都失败，不会存在一个成功一个失败的情况。
库存系统：在多个仓库之间进行库存转移或销售操作时，需要确保库存的一致性，防止商品超卖或库存混乱。
订票系统：需要确保预订信息的一致性，避免出现同一个资源被多次预订的问题。
Zookeeper：可作为注册中心，支持CP，拿主节点选举举例，当主节点异常进行选举，选举期间所有节点不可用，保证数据的一致性。
Redis：Redis主从模式是CP模式，当主从通信异常此时无法向主节点写数据。
Nacos：Nacos也支持CP，不过默认是AP模式，当客户端注册为非临时节点时为CP模式，注册为非临时节点就需要实时上报心跳，即使在一段时间内未收到心跳信息，该实例仍然会保留在服务列表中，适用于配置中心。
符合AP的场景：满足A舍弃C，强调可用性。
AP强调的是可用性，允许短暂的不一致但是要保证最终一致性，在实际应用中符合AP的场景较多。
订单退款：退款后状态为退款中，24小时后退款金额到帐。
积分系统：注册送积分，注册成功积分在24小时后到账。
跨行转账：一般转账支持CP，还有的支持AP，源账号扣减金额后需要等一段时间目标账户才到账，或者源账号扣款后由于目标账号有问题过一段时间将转账金额退回到源账户。
MySQL主从复制：支持AP，向主节点写数据，异步同步到的从节点。
Nacos：默认支持AP，即临时节点的情况，会实时上报心跳，如果一段时间内未收到心跳信息，Nacos 会将该实例标记为不可用并从服务列表中移除。
在生产中AP场景应用的更多，强调的是可用性,允许出现短暂不一致，最终达到数据一致性。
