重复消费

存在强校验与软校验两种方式
强校验单独增加一张流水或历史表，要操作的表与流水表一起触发事物，每次执行前先查询流水表中是否存在对应的id
弱校验是把唯一标识与场景码存放到 缓存中，过期时间看场景，一定时间之内就去缓存中判断

顺序消费

同一个场景下不同的几个业务操作发出去，发出时是顺序的，但消费时不是顺序。可能会导致增改删变成删改增。
同一个唯一标识操作的放到同一队列里同步发送，这样可以保证消费者接收到的业务顺序。

分布式事务

网上查询到的事务方式有：

  • 2pc（两段式提交）
  • 3pc（三段式提交）
  • TCC（Try、Confirm、Cancel）
  • 最大努力通知
  • XA
  • 本地消息表（ebay研发出的）
  • 半消息/最终一致性（RocketMQ）

我之前采用的都是最大努力通知，发送一个延时队列，如果触发了就判断主表是否成功，如果没有成功就修改对应的从表数据。

两段式提交，是由消息中间件协调多个系统服务 ，系统服务都准备好事务但不提交，等待消息中间件收到所有的系统准备好了，发动统一提交。

最终一致性
消息中间件的重复消费/顺序消费/分布式事务 - 图1
我们可以保证主动推送方失败的话，被动接收方事务不会成功。
主动方事务成功，被动接收方一定会接收到消息。