chuixue24的博客

github：https://github.com/codingapi/tx-lcn5.x版本文档见https://www.codingapi.com/docs/txlcn-preface/

什么情况下需要使用分布式事务？使用的场景很多，先举一个常见的：在微服务系统中，如果一个业务需要使用到不同的微服务，并且不同的微服务对应不同的数据库。打个比方：电商平台有一个客户下订单的业务逻辑，这个业务逻辑涉及到两个微服务，一个是库存服务（库存减一），另一个是订单服务（订单数加一），示意图如下：如果在执行这个业务逻辑时没有使用分布式事务，当库存与订单其中一个出现故障时，就很可能出现这样的情况：库存数据库的值减少了1，但是订单数据库没有变化；或是库存没变化，多了一个订单，也就是出现了数据不一致

一、简介LCN分布式事务框架其本身并不创建事务，而是基于对本地事务的协调从而达到事务一致性的效果。LCN5.0.2有3种模式，分别是LCN模式，TCC模式，TXC模式 LCN模式： LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。 该模式的特点： - 该模式对代码的嵌入性为低。- 该模式仅限于本地存在连接对象且可通过连接对象控制事务的

一、可靠消息最终一致性事务概述可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息中间件完成，如下图：事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。因此可靠消息最终一致性方案要解决以下几个问题：【1】本地事务与消息发送

分布式事务产生的条件说到分布式事务，我们先来看看分布式事务的产生条件这里我们举一个栗子：当用户进行下单以后，会去调用派单服务进行派单，即向派单服务数据库中插入一条派单业务。 派单成功之后，订单服务在执行后面的业务代码中，报错了 此时订单服务事务回滚，而派单服务的事务已经提交了，导致了数据的不一致。此时，小伙伴可能有疑问：派单服务报错呢？会不会也产生分布式事务问题？实际上如果派单服务报错，会将执行结果返回给订单服务，订单服务执行相应的处理即可，并不会发生分布式事务。什么是分...

Seata分TC、TM和RM三个角色，TC（Server端）为单独服务端部署，TM和RM（Client端）由业务系统集成。因此，客户端承担了TM和TM的角色。服务端见博文：https://blog.csdn.net/chuixue24/article/details/108071970本文为实现seata分布式事务中的AT模式。seata客户端——服务提供端执行脚本客户端也需要执行sql脚本：-- for AT mode you must to init this sql for

seata官方地址：http://seata.io/zh-cn/index.htmlseata官方文档地址：http://seata.io/zh-cn/docs/overview/what-is-seata.html安装包下载地址：http://seata.io/zh-cn/blog/download.htmlgithub地址：https://github.com/seata/seata官方部署指南：http://seata.io/zh-cn/docs/ops/deploy-guide-be

由于项目上的需要，我要同时往orcale数据库与sqlserver数据中插入数据，需要在一个事务之内完成这两个库的提交。参考了一下网上的各种JTA（Java Transaction API）实现之后，选择了Atomikos的实现。因为当时使用的时候绕的弯路大了点，所以写篇文章记录下基本的实现过程，方便日后查看。如果是第一次使用，强烈建议去Atomikos查看官方例子与指导，写的很详细。前提...