Raincat，强一致性分布式事务，是基于二阶段提交+本地事务补偿机制来实现。原理介绍
基于java语言来开发（JDK1.8），支持dubbo,motan,springcloud进行分布式事务。
因为文件名太长，大家在拉取代码的时候执git命令：git config --global core.longpaths true
Features
-
框架特性
-
无缝集成spring 或 spring boot。
-
支持dubbo,motan,springcloud,等rpc框架进行分布式事务。
-
事务发起者，参与者与协调者底层基于netty长连接通信,稳定高效。
-
协调者采用eureka做注册中心，支持集群模式。
-
采用Aspect AOP 切面思想与Spring无缝集成。
-
配置简单，集成简单，源码简洁，稳定性高，已在生产环境使用。
-
内置经典的分布式事务场景demo工程，并有swagger-ui可视化界面可以快速体验。
-
-
事务角色
-
事务发起者（可理解为消费者 如：dubbo的消费者,springcloud的调用方）,发起分布式事务
-
事务参与者（可理解为提供者 如：dubbo的提供者,springcloud的rest服务提供者),参与事务发起者的事务
-
事务协调者（tx-manager），协调分布式事务的提交，回滚等。
-
-
技术方案
-
协调者（tx-manager）采用eureka作为注册中心，集群配置，达到服务的高可用，采用redis集群来分布式存储事务数据, springboot 提供rest服务，采用netty与参与者，发起者进行长连接通信。
-
发起者与协调者，采用Aspect AOP 切面思想，SPI，多线程，异步回调，线程池，netty通信等技术。
-
-
SPI扩展
- 本地事务恢复，支持redis，mogondb，zookeeper，file，mysql等关系型数据库
- 本地事务序列化保存，支持java，hessian，kryo，protostuff
- netty通信序列化方式，支持 hessian，kryo，protostuff
Prerequisite
-
JDK 1.8+
-
Maven 3.2.x
-
Git
-
RPC framework dubbo or motan or springcloud。
架构设计
-
架构设计图 ：
-
流程图 ：
视频源码分析
环境搭建
启动过程
事务提交
回滚恢复
管理后台
Support
-
如有任何问题欢迎加入QQ群进行讨论
-
微信公众号
Contribution
-
在每个角色-发起方，参与方都有事物service层注解 1，一个线程去执行切点任务，扫master的协调操作信息 ----第一阶段：操作session持久化状态 2，主线程等待，等步骤1的线程返回指令后，提交事物或回滚事物 ----第二阶段：从session最总提交commit数据库，或回滚就是直接变为游离态 业务切面中的方法操作的还是在数据库内存中持久态的对象，最终commit才会
-
一、前言 关于2PC的理论知识请见：分布式_理论_03_2PC 这一节我们来看下github上一个优秀的2PC分布式事务开源框架的快速体验。 二、源码 源码请见： https://github.com/yu199195/Raincat 相关视频 http://www.iqiyi.com/u/1243078745/v 三、接入步骤 1.启动 TxManagerApplication 此工程为分布式事
-
一、前言 关于2PC的理论知识请见：分布式_理论_03_2PC 这一节我们来看下github上一个优秀的2PC分布式事务开源框架的快速体验。 二、源码 源码请见： https://github.com/yu199195/Raincat 相关视频 http://www.iqiyi.com/u/1243078745/v 三、接入步骤 1.启动 TxManagerApplication 此工程为分布式事
-
我目前正在阅读微服务模式，它说分布式事务主要有两种方法：两阶段提交（2PC）和sagas模式。 此外，我听说了目前正在发展的分布式SQL（DSQL）工具，如CockroachDB、YuGabyteDB和YDB，它们还通过自己的低级db节点通信支持分布式ACID类事务。 那么问题是，后者是否可以作为前者的替代方案？ 为了说明这个问题，考虑以下典型的微服务分布式事务示例。这里我们需要2PC或sagas
-
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，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一
-
分布式事务基于 JTA/XA 规范实现 1。 两阶段提交： 1. 本功能暂未实现 ↩