分布式事务读书笔记

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u011648791/article/details/82492802

总体原理

理论解释：

https://blog.csdn.net/congyihao/article/details/70195154

最终一致性，如sharding-jdbc的弱事务也是最终一致性

强一致性

本地事务采用刚性事务, 分布式事务使用柔性事务

旧解决方案：

两阶段提交(2PC)，TCC (Try-Confirm-Cancle)

新解决方案

异步确保型

适用场景

• 执行周期较长
• 实时性要求不高

方式一：基于MQ方式的普通MQ和RocketMQ最终一致性

http://www.itboth.com/d/7BVfi2JzAz2e/springcloud-rabbitmq-java-spring

第二个事务失败则需要做补偿机制回滚第一个事务。但是过于麻烦，所以第二个事务必须成功。所以这种为最终一致性，一定要受理成功，如银盾，如资管到通知财务放款

为什么有中间的可靠消息呢？可靠消息可以用数据库，不一定用中间系统。

本地消息表（异步确保）和MQ 事务消息

https://www.cnblogs.com/aoshicangqiong/p/7726323.html

事例

银盾，懒猫，厦门银行必须受理，不行就重试，垫资户没钱也不能说受理失败，会等到有钱就继续流程。

支付宝转账RocketMq

http://blog.jobbole.com/89140/ 

3.1.2 业务与消息解耦方式

讲述为什么要单独一个服务

优缺点

如何解决消息重复投递的问题

可以防止像淘宝这种抢下单

银行

https://www.cnblogs.com/xybaby/p/7465816.html

乐观锁update

delta值update

update后insert数据库记录，唯一索引

方式二：基于http的LCN强一致性

https://blog.csdn.net/zyndev/article/details/79604395

https://blog.csdn.net/woaixinxin123/article/details/73826653

https://www.txlcn.org/

电商系统抢单，抢货