seata与MQ用分布式事务区别

本博只是自己刚学习seata的思路，若有问题可以指出

举个栗子，如RabbitMQ

1.先说MQ。我们用户一个下订单一个事务，在OrderProvider的service里通过Feign远程调用：

    @Autowired
	private RabbitTemplate templete;

    public void startkill(Long id, String money,String count) {
		
		//写入rabbitmq的消息内容需要先封装一下
		String msg = id + "/" + money+ "/" + count;
		
		//利用id可以在消费端获取商品信息,一旦秒杀成功,减少库存
		//userPhone作为用户信息,成功则入库,失败则返回
		//将消息写入队列
		templete.convertAndSend("rabbitmq-seckill", "seckill", msg);
		
	}

 

2.在发送端发送消息后，AccountProvider和StorageProvider就可以消费端接收这个“msg”，进行减库存，减余额操作。当然，要记录像seata使用的前镜像和后镜像记录Account和Storage的数据库undo段。并且要通过一个全局ID来记录这些操作，并保存到表里。

(到这里我已经完全跟着seata的思路走了😅)

 

---------------------------

这里说下为什么用MQ:

1.解耦。

现在有 Service A / Service B，三者构成某分布式事务。

如果用 rpc，A / B 彼此是不是得知道对方（哪怕用注册中心不也有个调用过程）？用消息队列的话，彼此压根不需要知道对方，只需要跟消息队列打交道就可以了。

你硬要用 rpc 也行，那这时候又多俩 Service C / Service D 出来呢？你回过头还得去改 A / B 的代码吗？都你自己写的你说你费点儿劲，那也行；如果是两个不同 Team 在干活呢？人家凭啥加班帮你改，自己的任务不做了吗？

 

2.mq的作用就是解耦、异步、削峰，实现分布式事务的最终一致性，是柔性事务。
不考虑并发，直接rpc或http就需要考虑分布式事务如何保证，当然也有对应的分布式事务框架可以补。
两种实现没有优劣之分，针对不同场景使用不同的方式，只不过mq在高并发中比较常见。

-----------------------------

 

3.当AccountProvider的减余额操作超时或失败了。通过OrderProvider的try{...}catch{从回滚表记录的开始回滚}

具体步骤没有我没有去实现，可能写着写着会发现不太对=。=(太懒了，等有时间再补)

 

seata专门用分布式事务的，官方文档说的更清楚：

http://seata.io/zh-cn/docs/overview/what-is-seata.html