分布式事务
若是系统规模较小，数据表都在一个数据库实例上，上述本地事务方式能够很好地运行，
可是若是系统规模较大，好比用户A帐户表和用户B帐户表显然不会在同一个数据库实例上，他们每每分布在不一样的物理节点上，这时本地事务已经失去用武之地。数据库
分布式事务解决方法
两阶段提交(屡次节点间的通讯,事务时间较长,锁定资源的时间较长,不适合高并发系统)
消息(最终一致性)
数据 在一段时间是不一致的,可是最终可以实现一致性,能够提升并发量,
好比,如今不少饭店都是小票排号,你点了什么菜,饭点的时候人不少,不能点了菜,立刻就能上菜,可是你已经排上号了,最终都会给你上菜的.这就是最终的一致性. 很显然这样可以提升接待能力.
消息与业务耦合
Begin transaction
update A set amount=amount-10000 where userId=1;
insert into message(userId, amount,status) values(1, 10000, 1);//这里不直接发送消息 是由于若是消息发送了,可是B没有收到,这条链路就断了
End transaction
commit;
定时任务读取A消息表 发送消息
当上述事务提交成功后，咱们经过实时消息服务将此消息通知用户B，用户B处理成功后发送回复成功消息，用户A收到回复后修改该条消息数据的状态。
用户A收到回复消息,,把消息从消息表中删除,并插入到消息备份表中,(可用于消息补偿)
防止消息的屡次投递. 在B端作幂等控制, 在B端记录消息的消费状况
B端执行的状况的时候,都要先去查询一下这个消息是否存在,若是存在直接放弃.若是不存在就执行B的加钱操做,而后往消息表里面插入接收到的消息数据.这些操做在一个事务里面架构
定时任务去检索消息表,发送消息消费成功回调消息给A
消息与业务解耦
上述保存消息的方式使得消息数据和业务数据紧耦合在一块儿，从架构上看不够优雅，并且容易诱发其余问题。为了解耦，能够采用如下方式。并发
1）用户A在扣款事务提交以前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送，只有消息发送成功后才会提交事务；分布式
2）当用户A扣款事务被提交成功后，向实时消息服务确认发送。只有在获得确认发送指令后，实时消息服务才真正发送该消息；高并发
3）当用户A扣款事务提交失败回滚后，向实时消息服务取消发送。在获得取消发送指令后，该消息将不会被发送；接口
4）对于那些未确认的消息或者取消的消息，须要有一个消息状态确认系统定时去用户A系统查询这个消息的状态并进行更新。为何须要这一步骤，
举个例子：假设在第2步用户A扣款事务被成功提交后，系统挂了，此时消息状态并未被更新为“确认发送”，从而致使消息不能被发送。事务
优势：消息数据独立存储，下降业务系统与消息系统间的耦合；资源
缺点：一次消息发送须要两次请求；业务处理服务须要实现消息状态回查接口。it