在分布式微服务架构应用中如何实现最终一致性？

 在分布式系统中，分布服务实现强一致性并不容易。式微实现即使2PC、架构3PC阶段提交，应用也无法保证绝对的中何最终致性强一致性。

我们也不能因为极小的分布服务不一致性概率，导致系统整体性能低下，式微实现或者扩展性受到影响，架构并且架构也变得极其复杂。应用因此，中何最终致性在2PC/3PC提交缺乏大规模应用的分布服务情况下，最终一致性是式微实现一个较好的方案，在业界得到了大量使用。架构

一、应用重试机制

如下图所示，中何最终致性Service Consumer 同时调用 Service A 和 Service B，如果Service A 调用成功，Service B 调用识别，为了保证最终一致性，最简单的办法是重试。

重试的时候，要注意设置Service Consumer 的超时时间， 避免长时间等待或卡死，耗尽资源。

Consumer 重试时，服务器租用需要注意如下几个方面：

超时时间； 重试的次数； 重试的间隔时间； 重试间隔时间的衰减度；

具体实现细节，可以参考《 基于Spring-tryer 优雅的重试方案》。

二、本地记录日志

通过本地记录日志，然后收集到分布式监控系统或者其他后端系统中，启动一个定期检查的工具。根据实际情况，可以选择人工处理。

日志格式：TranID-A-B-Detail

TransID为事务ID，可以生成一个随机序列号； Detail 为数据的详细内容； 如果调用A成功，则记录 A success； 如果调用B失败，或者出现故障，没有记录等等，也就是日志中没有B success，则重新调用B； 可以定期检测，并处理日志。

收集识别日志的设计图，如下所示。

三、可靠消息模式

考虑到实际业务场景中发生故障的概率概率比较低，可以考虑如下方案。

Service Consumer 在调用 Service B 失败，先进行重试。如果重试一定的网站模板次数仍然失败，则直接发送消息Message Queue，转换为异步处理。

可以采用分布式能力比较强的MQ，如Kafka、RocketMQ等开源分布式消息系统，进行异步处理。

Service B 可以专门集成一个错误处理的组件，不断从MQ 收集补偿消息。 或者独立一个错误处理的组件，独立处理MQ 的补偿消息，包括其他Service 组件的异常。

这种方案也有丢失消息的风险，就是Service Consumer 的消息还没有发出来就挂了，这是小概率事件。

还有一种方案-可靠消息模式，如下图所示。Service Consumer 发送一条消息给Message Queue Broker，如RocketMQ、Kafka等等。由Service A和Service B 消费消息。

MQ 可以采用分布式MQ，并且可以持久化，这样通过MQ 保证消息不丢失，云服务器提供商认为MQ 是可靠的。

可靠消息模式的优点：

提升了吞吐量； 在一些场景下，降低了响应时间；

存在问题：

存在不一致的时间窗口（业务数据进入了MQ，但是没有进入DB，导致一些场景读不到业务数据）； 增加了架构的复杂度； 消费者（Service A/B）需要保证幂等性；

针对上述不一致的时间窗口问题，可以进一步优化。

将业务分为：核心业务和从属业务 核心业务服务 - 直接调用； 从属业务服务 - 从MQ 消费消息；

直接调用订单服务（核心服务），将业务订单数据落地DB；同时，发送向MQ 发送消息。

考虑到在向MQ 发送消息之前，Service Consumer（创建订单）可以会挂掉，也就是说调用订单服务和发送Message 必须在一个事务中，因为处理分布式事务比较麻烦，且影响性能。

因此，创建了另外一张表：事件表，和订单表在同一个数据库中，可以添加事务保护，把分布式事务变成单数据库事务。

整个流程如下：

（1）创建订单 - 持久化业务订单数据，并在事件表中插入一条事件记录。注意，这里在一个事务中完成，可以保证一致性。如果失败了，无须关心业务服务的回退，如果成功则继续。

（2）发送消息 - 发送订单消息到消息队列。

如果发送消息失败，则进行重试，如果重试成功之前，挂掉了，则由补偿服务去重新发送消息（小概率事件）。 补偿服务会不断地轮询事件表，找出异常的事件进行补偿消息发送，如果成功则忽略。 如果发送消息成功，或者补偿服务发送消息成功，则可以考虑删除事件表中的事件信息记录（逻辑删除）。

（3）消费消息 - 其他从属业务服务，则可以消费MQ中的订单消息，进行自身业务逻辑的处理。

上述设计方案中，有3点需要说明一下：

（1）直接调用订单服务（核心业务），是为了让业务订单数据尽快落地，避免不一致的时间窗口问题，保证写后读一致性。

（2）创建订单业务直接发送消息给MQ，是为了增加实时性，只有异常的情况，才使用补偿服务。如果对实时性要求不高，也可以考虑去掉Message 直接发送的逻辑。

（3）额外引入一张事件表，是为了将分布式事务变成单数据库事务，在一定程度上，也增加了数据库的压力。