CAP 是一个在分布式系统中（SOA，MicroService）实现事件总线及最终一致性（分布式事务）的一个开源的 C# 库，她具有轻量级，高性能，易使用等特点。
你可以轻松的在基于 .NET Core 技术的分布式系统中引入CAP，包括但限于 ASP.NET Core 和 ASP.NET Core on .NET Framework。
CAP 以 NuGet 包的形式提供，对项目无任何入侵，你仍然可以以你喜爱的方式来构建分布式系统。
CAP 具有 Event Bus 的所有功能，并且CAP提供了更加简化的方式来处理EventBus中的发布/订阅。
CAP 具有消息持久化的功能，也就是当你的服务进行重启或者宕机时，她可以保证消息的可靠性。
CAP 实现了分布式事务中的最终一致性，你不用再去处理这些琐碎的细节。
CAP 提供了基于 Microsoft DI 的 API 服务，她可以和你的 ASP.NET Core 系统进行无缝结合，并且能够和你的业务代码集成支持强一致性的事务处理。
CAP 是开源免费的。CAP基于MIT协议开源，你可以免费的在你的私人或者商业项目中使用，不会有人向你收取任何费用。
下图是 CAP 集在 ASP.NET Core 微服务架构中的一个示意图：
图中实线部分代表用户代码，虚线部分代表 CAP 内部实现。
-
优质资源分享 学习路线指引（点击解锁） 知识定位 人群定位 李 Python实战微信订餐小程序 李 进阶级 本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。 Python量化交易实战 入门级 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 前言 今天，我们很高兴宣布 CAP 发布 6.1 版本正式版，在这个版本中我们主
-
前言 我们很高兴宣布 CAP 发布 6.1 版本正式版，在这个版本中我们主要针对目前已经发现的几个BUG进行了修复了以及添加了一些小特性。 那么，接下来我们具体看一下吧。 总览 可能有些人还不知道 CAP 是什么，老规矩来一个简介。 CAP地址：https://github.com/dotnetcore/CAP) 是一个用来解决微服务或者分布式系统中分布式事务问题的一个开源项目解决方案（https
-
一、添加Nuget引用 在Nuget中搜索DotNetCore.CAP.RabbitMQ并安装 二、在项目的StartUp中注入并配置服务 context.Services.AddCap(x => { // 配置数据库链接 //x.UseEntityFramework<OrderDbContext>();
-
主要内容：1.2PC,2.三阶段提交(3PC),3.补偿事务（TCC）,4.本地消息表,5.消息事务,6.最大努力通知,7.Sagas 事务模型1.2PC 两阶段提交 mysql是通过日志系统完成事务的。就是两阶段提交:undolog和binlog的两阶段提交。 两阶段协议可以用于单机集中式系统，由事务管理器协调多个资源管理器；也可以用于分布式系统，由一个全局的事务管理器协调各个子系统的局部事务管理器完成两阶段提交。 第一阶段:投票阶段 1.协调者写命令进写入日志 2.协调者发一个prepare
-
本文向大家介绍详解SpringBoot基于Dubbo和Seata的分布式事务解决方案，包括了详解SpringBoot基于Dubbo和Seata的分布式事务解决方案的使用技巧和注意事项，需要的朋友参考一下 1. 分布式事务初探 一般来说，目前市面上的数据库都支持本地事务，也就是在你的应用程序中，在一个数据库连接下的操作，可以很容易的实现事务的操作。 但是目前，基于SOA的思想，大部分项目都采用微服务
-
ShardingSphereTransactionManager SPI 名称 详细说明 ShardingSphereTransactionManager 分布式事务管理器 已知实现类 详细说明 XAShardingSphereTransactionManager 基于 XA 的分布式事务管理器 SeataATShardingSphereTransactionManager 基于 Seata 的分
-
ShardingSphere-Proxy 接入的分布式事务 API 同 ShardingSphere-JDBC 保持一致，支持 LOCAL，XA，BASE 类型的事务。 XA 事务 ShardingSphere-Proxy 原生支持 XA 事务，默认的事务管理器为 Atomikos。 可以通过在 ShardingSphere-Proxy 的 conf 目录中添加 jta.properties 来定
-
通过 Apache ShardingSphere 使用分布式事务，与本地事务并无区别。 除了透明化分布式事务的使用之外，Apache ShardingSphere 还能够在每次数据库访问时切换分布式事务类型。 支持的事务类型包括 本地事务、XA事务 和 柔性事务。可在创建数据库连接之前设置，缺省为 Apache ShardingSphere 启动时的默认事务类型。
-
背景 数据库事务需要满足 ACID（原子性、一致性、隔离性、持久性）四个特性。 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行。 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态。 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。 持久性（Durability）指已提交的事务修改数据会被持久
-
单文档原子性可满足大多数业务需求 在 MongoDB 中，对单个文档的操作是原子操作。 由于 MongoDB 文档数据模型，一个文档中通过嵌入式的文档和数组来表示传统关系数据库模型中的一对一、一对多关系，而不是通过文档之间的复杂关系来描述业务需求中的一对一、一对多关系。 所以单文档原子性可以满足实际生产中大多数关于事务的需求。 对于需要对多个文档（在单个或多个集合中）进行原子读写的情况，Mongo
-
两阶段提交协议 通常在复杂场景下是不推荐使用的，除非是非常简单的场景，非常容易提供回滚，而且依赖的服务也非常少的情况。 这种实现方式会造成代码量庞大，耦合性高。而且非常有局限性，因为有很多的业务是无法很简单的实现回滚的，如果串行的服务很多，回滚的成本实在太高。 本地消息表 这种实现方式的思路，其实是源于ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一