需要注意的是标题中的CAP不是指的CAP理论，而是园区大神杨晓东实现的框架，CAP框架基于本地消息表用最终一致性实现分布式事务。

本地消息表

首先我们考虑一个场景，在将用户信息更改后，需要发送一条消息到消息队列、缓存或是写入到其他库中。这个过程涉及到一个本地库与MQ、本地库与Cache或是本地库与其他库两者之间的事务问题，不能用简单的数据库事务控制了。

这种分布式事务下，常用的解决方案有2PC、3PC等强一致性保证的，也有TCC、Sagas模型、本地消息表、内嵌本地消息表的MQ等最终一致性保证的。

而在很多异步场景下，允许系统存在短暂的不一致，只需达到最终一致，比起强一致性那种刚性事务，采用柔性事务，在很多场景下更有利于我们去实现。

执行过程

在使用CAP框架前，先熟悉下作为分布式事务解决方案之一的本地消息表工作过程。

1. 消息发起方(如图左侧部分)和消息接收方(如图右侧部分)，先额外建一套消息表，用来记录及跟踪消息内容及状态。
2. 当有请求到消息发起方时，处理完业务逻辑发布消息将业务数据和消息数据一同提交到本地表中，此时为本地事务。
3. 本地事务没有问题后，将消息发送到MQ传递给消息消费方。如果消息发送失败，会进行重试发送。
4. 消息消费方，接收并处理消息，完成自己的业务逻辑，此时为消息消费方本地事务，如果本地事务完成，则更改接收消息的状态，更改本地，如果处理失败，那么可再次重试执行。
5. 最终，左侧事务与右侧事务达到最终一致。

CAP框架

CAP是一个在分布式系统中（SOA，MicroService）实现事件总线及最终一致性（分布式事务）的一个开源的 C# 库，具有轻量级，高性能，易使用等特点。

• 具有 Event Bus 的所有功能，提供了更加简化的方式来处理EventBus中的发布/订阅。
• 具有消息持久化的功能，当服务进行重启或者宕机时，可以保证消息的可靠性。
• 基于本地消息表实现了分布式事务中的最终一致性。

• 集成了可视化页面方便观察消息状态。

• 提供了一系列Nuget包以选择需要的工具接入。

1. 第一个包DotNetCore.CAP为必须要安装的。
2. 可以依据消息队列的不同选择用RabbitMQ、Kafka或是AzureServiceBus等。
3. 根据服务使用的数据库情况选择需要将本地消息表落库，可以选择SqlServer、MySql、PostgreSql、MongoDB等，或是直接使用内存存储，方便快速实践。

场景案例

依照EShopOnContainers中的一张图来实现一个例子，用户更新用户信息，将更新的部分通过事件发送到消息队列中，下游的购物车和订单服务侦听到消息，更改买家信息。

在此基础上行，设计三个上下文，并分别集成CAP,借助RabbitMQ作为消息队列，对于UserService、BasketService和OrderService,都直接使用了数据库（当然可以不仅限于数据库）。

服务建立

项目创建

开始建立几个服务，新建空白解决方案，依次建立三个WebApi项目，并移除默认的控制器。

简单设计下，在三个服务中创建三个DbContext，对应三个独立的数据库。

• UserService中创建UserInfo实体及UserDbContext
• BasketService中创建Basket实体及BasketDbContext
• OrderService中创建Order实体及OrderDbContext

安装Nuget包

在三个服务中均安装完如下选中的包，此次Demo中为方便快速实践，选择RabbitMQ作为消息队列，MySql作为数据库存储。

对于EFCore及MySql包，安装了如下几个包

Microsoft.EntityFrameworkCore
Microsoft.EntityFrameworkCore.Design
Microsoft.EntityFrameworkCore.Tools
Pomelo.EntityFrameworkCore.MySql