最近面试了几位开发的同学，聊到消息最终一致性方案，有的完全没用过也没看过有的用过也说不清楚，但是这个比起GTS这些，算是几年前的老话题了,如是准备再理一理：
基于本地消息服务最终一致性方案
核心： 将业务逻辑与消息记录放在同一个事务里边执行， 业务逻辑执行与消息记录一致.
- 1，本地业务数据处理
- 2.1本地消息数据处理(1+2.1需要在同一个事务)，要么成功，要么失败
- 2.2 发送消息给mq
- 3，消息投递到Consumer消费端
- 4,消费端服务处理业务数据
- 5，业务端业务数据消费成功，反馈给comsumer
- 6，comsumer返回ack非消息中间件MQ
- 7,发送ack消息，更新本地消息表，表示已经完成或者消费成功，修改消息状态
- 8，恢复系统定时轮询消息表，找出没有消费成功ack的消息
- 9，重新发送没有消费成功的消息
bad case
- 如果1，2.1出错，本地事务回滚，业务数据，消息都没有变化，啥都没做
- 如果2.2 发送失败，定时任务系统会查询消息表，依据状态重新发送
- 3-7步骤出错，也没法ack本地消息表，都会重新发送消息
- 既然会重新发送消息，那消费端就要考虑重复消息的问题，也就是幂等，尤其是在7.1/7.2确认过程中失败了，一旦重复发送，如果不幂等，业务逻辑就会重复执行，如果是减库存或者支付场景，就会出现多加或者多减数据，出现不一致
基于独立消息服务的最终一致性方案
异常case： 业务执行成功或者失败，但是没有确定状态，导致中间件消息状态一直为”待处理”状态
RocketMQ类支持事务最终一致性方案
下游
幂等问题：
下游消费服务，正常情况下都会ack消费消息的状态，但是也存在消息处理完之后一直没有ack消费状态的情况， 这时就会出现重复消费消息，如果之前业务没有执行成功， 重复消费是没有问题的
但是如果之前的消息业务逻辑处理成功了， 再次消费就可能出现问题了。所以这个时候就必须考虑幂等的问题