微服务保持事物的一致性

解决方案一：

​ 使用中间表控制微服务之间的事物的一致性，即在A，B两个微服务中，是一个游戏买装备的业务流程，A微服务负责扣除用户的金币，B微服务负责生成相应的订单数据，在我们用户够买装备时，当A服务扣除金币成功时相应的B微服务有以下几处理结果态:①成功②失败③超时 当B微服务发生二或者是三中的一种时即事物不能保持一致性，此时我们可以采用中间表的机制实现微服务间事物的一致性。我们设计一个中间表用来存放用户够买装备的A,B两个微服务的状态，当我们A完成时状态为1B完成时状态为1，B失败时状态为0，我们设置一个定时的轮循查询该表数据，若A,B状态不一致则进行相应的事物控制，则可以实现微服务之间的事物的一致性。

 

解决方案二:

MQ（非事务消息）

​ 通常情况下，在使用非事务消息支持的MQ产品时，我们很难将业务操作与对MQ的操作放在一个本地事务域中管理。通俗点描述，还是以上述提到的“跨行转账”为例，我们很难保证在扣款完成之后对MQ投递消息的操作就一定能成功。这样一致性似乎很难保证。

先从消息生产者这端来分析，请看伪代码：

根据上述代码及注释，我们来分析下可能的情况：

1. 操作数据库成功，向MQ中投递消息也成功，皆大欢喜

2. 操作数据库失败，不会向MQ中投递消息了

3. 操作数据库成功，但是向MQ中投递消息时失败，向外抛出了异常，刚刚执行的更新数据库的操作将被回滚

从上面分析的几种情况来看，貌似问题都不大的。那么我们来分析下消费者端面临的问题：

1. 消息出列后，消费者对应的业务操作要执行成功。如果业务执行失败，消息不能失效或者丢失。需要保证消息与业务操作一致

2. 尽量避免消息重复消费。如果重复消费，也不能因此影响业务结果

如何保证消息与业务操作一致，不丢失？

主流的MQ产品都具有持久化消息的功能。如果消费者宕机或者消费失败，都可以执行重试机制的（有些MQ可以自定义重试次数）。

如何避免消息被重复消费造成的问题？

1. 保证消费者调用业务的服务接口的幂等性

2. 通过消费日志或者类似状态表来记录消费状态，便于判断（建议在业务上自行实现，而不依赖MQ产品提供该特性)

总结：这种方式比较常见，性能和吞吐量是优于使用关系型数据库消息表的方案。如果MQ自身和业务都具有高可用性，理论上是可以满足大部分的业务场景的。不过在没有充分测试的情况下，不建议在交易业务中直接使用。