本文参考《持续演进的Cloud Native云原生架构下微服务最佳实践》一书整理而成,分析了在分布式系统中,如何实现最终一致性。
![b50b32d1929062d47fd9170e3eed9fea.png](https://i-blog.csdnimg.cn/blog_migrate/05fbb1d0600430c5360ca99bfdc69196.jpeg)
如何实现最终一致性?
在分布式系统中,实现强一致性并不容易。即使2PC、3PC阶段提交,也无法保证绝对的强一致性。
我们也不能因为极小的不一致性概率,导致系统性能低下,或者扩展性受到影响,并且架构也变得极其复杂。因此,在2PC/3PC提交缺乏大规模应用的情况下,最终一致性是一个较好的方案,得到了大量使用。
(1) 重试机制
如下图所示,Service Consumer 同时调用 Service A 和 Service B,如果Service A 调用成功,Service B 调用识别,为了保证最终一致性,最简单的办法是重试。
![128c84174495e69740ccde7934396f5e.png](https://i-blog.csdnimg.cn/blog_migrate/ede87dd771fe201b487ab80d9b382016.jpeg)
重试的时候,要注意设置Service Consumer 的超时时间, 避免长时间等待或卡死,耗尽资源。
Consumer 重试时,需要注意如下几个方面:
- 超时时间;
- 重试的次数;
- 重试的间隔时间;
- 重试间隔时间的衰减度;
具体实现细节,可以参考《 基于Spring-tryer 优雅的重试方案》。
(2) 本地记录日志
通过本地记录日志,然后收集到分布式监控系统或者其他后端系统中,启动一个定期检查的工具。根据实际情况,可以选择人工处理。
日志格式:TranID-A-B-Detail
- TransID为事务ID,可以生成一个随机序列号;
- Detail 为数据的详细内容;
- 如果调用A成功,则记录 A success;
- 如果调用B失败,或者出现故障,没有记录等等,也就是日志中没有B success,则重新调用B;
- 可以定期检测,并处理日志。
收集识别日志的设计图,如下所示。
![2d9a1ffd90806a40a75d638853374d3a.png](https://i-blog.csdnimg.cn/blog_migrate/dd45eb9b3d985e82f665424cf4329e82.jpeg)
(3) 可靠消息模式
考虑到发送故障的概率概率比较低,可以考虑如下方案。
Service Consumer 在调用 Service B 失败,先进行重试。如果重试一定的次数仍然失败,则直接发送消息Message Queue,转换为异步。
可以采用分布式能力比较强的MQ,进行异步处理。
- Service B 可以专门集成一个错误处理的组件,不断从MQ 收集补偿消息。
- 或者独立一个错误处理的组件,独立处理MQ 的补偿消息,包括其他Service 组件的异常。
![7a5778d107bad349aa70137a935bcd09.png](https://i-blog.csdnimg.cn/blog_migrate/e490fe5c8fb130ad98ba2d66df978ebb.jpeg)
这种方案也有丢失消息的风险,就是Service Consumer 的消息还没有发出来就挂了,这是小概率事件。
还有一种方案-可靠消息模式,如下图所示。Service Consumer 发送一条消息给Message Queue Broker,如RocketMQ、Kafka等等。由Service A和Service B 消费消息。
MQ 可以采用分布式MQ,并且可以持久化,这样通过MQ 保证消息不丢失,认为MQ 是可靠的。
![aa3d16dca48a2265e580661b6335adb7.png](https://i-blog.csdnimg.cn/blog_migrate/f977647c6cd65bca2a4a1fbc88309d8c.jpeg)
可靠消息模式的优点:
- 提升了吞吐量;
- 在一些场景下,降低了响应时间;
存在问题:
- 存在不一致的时间窗口(业务数据进入了MQ,但是没有进入DB,导致一些场景读不到业务数据);
- 增加了架构的复杂度;
- 消费者(Service A/B)需要保证幂等性;
针对上述不一致的时间窗口问题,可以进一步优化。
- 将业务分为:核心业务和从属业务
- 核心业务服务 - 直接调用;
- 从属业务服务 - 从MQ 消费消息;
![4d1678e5afe47764ada7e76a3aec4521.png](https://i-blog.csdnimg.cn/blog_migrate/fea7b3ff1d6efc9810e8cabf0621c145.jpeg)
直接调用订单服务(核心服务),将业务订单数据落地DB;同时,发送向MQ 发送消息。
考虑到在向MQ 发送消息之前,Service Consumer(创建订单)可以会挂掉,也就是说调用订单服务和发送Message 必须在一个事务中,因为处理分布式事务比较麻烦,且影响性能。
因此,创建了另外一张表:事件表,和订单表在同一个数据库中,可以添加事务保护,把分布式事务变成单数据库事务。
整个流程如下:
(1)创建订单 - 持久化业务订单数据,并在事件表中插入一条事件记录。注意,这里在一个事务中完成,可以保证一致性。如果失败了,无须关心业务服务的回退,如果成功则继续。
(2)发送消息 - 如果发送消息失败,则进行重试,如果重试成功之前,挂掉了,则由补偿服务去重新发送消息(小概率事件)。
补偿服务会不断地轮询事件表,找出异常的事件进行补偿消息发送,如果成功则继续。
如果成功,则可以考虑删除事件表中的事件信息记录(逻辑删除)。
(3)消费消息 - 其他从属业务服务,则可以消费MQ中的订单消息,进行自身业务逻辑的处理。
上述设计方案中,有3点需要说明一下:
(1)直接调用订单服务(核心业务),是为了让业务订单数据尽快落地,避免不一致的时间窗口问题,保证写后读一致性。
(2)创建订单业务直接发送消息给MQ,是为了增加实时性,只有异常的情况,才使用补偿服务。如果对实时性要求不高,也可以考虑去掉Message 直接发送的逻辑。
(3)额外引入一张事件表,是为了将分布式事务变成单数据库事务,在一定程度上,也增加了数据库的压力。