1 布景

市面上常见的有，2pc/3pc、tcc、saga等常见的分布式业务处理方案，但是实践实施起来框架比较重，规划开发比较繁琐，不易于快速开发上手。本文供给一种根据柔性业务规划的简略易上手的分布式业务规划方案，用于处理常见的分布式业务常见场景。

2 常见分布式业务场景

2.1 同步场景

常见的场景，办法内依靠外部微服务多个同步接口，等同步接口回来再展开后续逻辑，如下图1描绘。

图1 分布式业务同步场景

存在的问题：B/C失利后，A/B不能回滚，造成数据不一致？

2.2 异步场景

办法内依靠外部微服务多个同步接口一起，本地业务提交并宣布异步MQ，如下图2描绘。

图2 分布式业务异步场景

存在的问题：询价系统无法确保本地业务和mq消息的发送一起成功或失利，会造成数据不一致。

3 处理方案

3.1 数据模型规划

业务表：记载每次同步办法履行的状况，包含：1-进行中（同步办法履行开端）、2-已完成（同步办法履行成功）、3-失利（同步办法履行失利）、4-已回滚（回滚办法履行成功）；

办法调用表：记载一个完好的业务内所有办法的履行前入参、同步办法接口、回滚接口、回滚入参、办法履行次序，如下图3描绘：

图3 业务服务数据模型

3.2 规划原理

原理：一个完好业务内，1.首要每个办法供给回滚接口，其次，业务内每次同步办法履行时，优先保护入参数据到业务表，方便后续做回滚补偿；2.整个业务内某一个办法履行失利时，完毕整个业务，并更新业务表状况=失利；3.业务表经过轮询状况status=3(失利)业务，调用回滚接口，利用回滚入参进行接口补偿；4.回滚逻辑：找到业务表中失利的履行办法的次序值，只调用小于失利次序值的所有回滚接口、入参，注意并不回滚失利值的接口，并根据次序倒序进行接口回滚补偿。

图4 回滚原理图

3.3 履行时序

图5 回滚履行时序图

3.4 回滚失利处理方案：

1. 业务服务的高可用确保：柔性业务前提是确保业务服务高可用性，重点确保；
2. 回滚服务重试机制：回滚接口失利重试机制，确保数据一致性；
3. 为了避免架构复杂度，做日志记载、报警、人工处理。

4 注意问题

1. 回滚服务的幂等性：回滚做好业务防重和系统防重，避免因为回滚带来的业务数据不一致；
2. 脏数据：整个业务中某一办法履行失利，前面调用办法的数据作为脏数据运用。简略的处理方案：依靠业务表整个业务履行状况来决定能否运用脏数据。但缺点就是这样会耦合业务逻辑；
3. 中心化：整个业务的保护完全依靠业务服务完成，需求确保业务服务的高可用性；
4. 实时性：业务保护本方案经过定时任务保护，假如业务场景有实时性要求，办法能够改为：在整个业务中某一办法履行失利时，catch反常，catch内更新任务状况成功时，直接进行回滚逻辑调用。

5 总结

除了经过惯例本地大业务确保业务完好性方案，本次方案供给了一套根据柔性业务回滚补偿的办法来确保分布式业务，经过保护业务服务和业务服务中心对应数据表，从而确保整个分布式业务的完好性。实现办法简略、轻量、易于操作，方便地处理了常见的分布式业务场景。

---

作者：郑朋辉