分布式事务到是什么

https://www.thebyte.com.cn/distributed-transaction/transaction.html

我这里介绍了 4 中分布式事务：BASE 、TCC 、SAGA 你可以看看。

我的理解简单来说就是原子性，只有成功和失败两种情况。

简单说就是一个 api 会经过多个微服务，其中一个挂了，导致数据对不上，比如给用户显示转账成功了，但是实际却扣钱了，但是钱没到另一个账号

事务和线程很相似，但又不是很相似。得先认识到并发线程原子性和事务原子性的区别。

一个是不可打断，不可继续分割；一个是存在回退机制，不会出现”错误数据“。

其它的就可以利用你”如何安全的并发编程“相关理论，来认识分布式事务。就像一个变量参与多个线程，一个数据同步到多个数据库。

你是如何控制这个变量在多个线程同步的？
- 锁：最简单的阻塞，同步
- 协程：有局限性但很合适的调度
- 事件/回调：可用但也仅仅可用

你又是如何控制这个服务在多个数据库保存操作中不会部分成功，部分失败的?
- 多个事务当然也可以阻塞：一致性拉满，可用性降低，与线程锁的特性高度一致。
- 多个事务当然也可以协作：可用性提高，一致性降低。倾斜程度根据协作方式而定，
- 多个事务当然也可以回调：或许就是最终一致性了，到回调完成那一刻，数据才会变得正确。

我认为分布式事务本身没什么复杂的，更多是因为涉及分布式事务的业务太复杂了。导致分布式事务看起来很难。其实回到本质还是同步问题。

从来不用分布式事务, 都是调接口, 成功了就算了, 不成功, 就调回退接口, 回退接口也失败了, 打日志告警人工处理.
现实中哪有真正的分布式事务? 你一次捞到多个数据库连接, 依次开启事务, 执行 sql, 然后 commit 的时候, 有几个成功了, 有几个失败了, 你怎么办? 提供成功的事务, 哪个数据库支持回滚? 就算支持回滚, 也会出现有几个回滚成功了, 有几个回滚失败了, 这时候你又咋办?

先从事务讲起，单体服务的事务 ACID 由 spring 管理、数据库保证
然后讲微服务下，A 服务调用 B 服务，为什么原来能在单体用的事务不生效了
接着讲怎么解决，讲最终一致性（本地消息表、事务消息）、强一致性（ 2PC 、TCC ）
讲市面上对应的中间件 rocketmq ？ seata ？
最后说你们项目怎么做的

@laminux29 #13 银行 app 和云闪付 app 里的信用卡账单都能做到实时，而短信的账单就会延迟就是为了省成本，发短信是要钱的，银行有几块钱包月实时短信通知的业务。所以这和分布式事务有啥关系？

@bthulu 对的，这才是真实的世界。

@ilvsxk

我并没有提银行 APP 与云闪付 APP ，请仔细的，认真的，阅读我在上面写的评论。做技术，一定要仔细认真。

@bthulu

Q1：现实中是否存在真正的分布式事务?
A：存在。

Q2：几个成功了, 有几个失败了, 你怎么办？
A：只要有一个失败，此次分布式事务就按失败算。分布式框架或相关驱动模组，会自动回滚所有涉及到的分布式数据库，如果你是开发，此时你会 catch 到一个分布式事务失败的 Exception ，你需要做的是，按此次业务失败进行处理。

Q3：提供成功的事务, 哪个数据库支持回滚?
A：主流的关系型数据库，必然支持回滚，这是标准。

Q4：就算支持回滚, 也会出现有几个回滚成功了, 有几个回滚失败了, 这时候你又咋办?
A：关系型数据库在正常情况下，回滚一定会成功。如果出现回滚失败，这等同于数据库软件出错，此时数据库软件会写日志告警，甚至失去响应、崩溃。如果你是运维，在数据库部署阶段，就要对这些情况进行监控。如果你只是开发，你什么都不用管，问一下运维同事就行。

以上知识在 [数据库原理与设计] 相关教程中有讲解，课程方面属于计算机系的本科课程。

@pangdundun996

1.本来我想用转账的例子来说明，但觉得太简单了，不符合本论坛水准。

2.我举得这个例子很合适，你说的双信息系统是对的，但你说的夜间跑批清算是错的，清算早就是全天候的了，真正原因我在评论区里已经讲了。

@laminux29
对对对，你是中肯的，仔细的，认真的，做技术的，会阅读的，会评论的。

@bthulu {哭笑脸} “打日志警告人工处理”，项目初期很受用。

@laminux29 commit 后还能 rollback 的数据库, 是谁? oracle, mysql, sql server 还是 postgresql?

@bthulu

1.我在前面说的，是规则，像 RFC 一样，是大家都需要遵循的规范，而不是某款关系型数据库的专有功能。

2.从你这个提问来看，你应该不是科班的。如果你对这个话题感兴趣，可以补习一下相关知识：
https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_txns.htm

@laminux29 可能你自己需要补习一下. 二阶段提交过程中, 部分成功, 部分失败, 这个时候你如何回滚? 我说的一直都是提交成功后的回滚, 不是说 commit 前的回滚.

@bthulu 所有的分布式事务, 都在规避提交 commits 的过程中, 部分成功, 部分失败后的处理方案. 为什么? 因为这种情况下根本就无法自动处理. 部分失败的数据, 难道你还能锁定数据中止服务死等到底提交还是不提交?