1

为什么要做服务之间的数据一致性

作为互联网公司的研发工程师，微服务的架构思想对于各位读者朋友来说，已经不是陌生东西。我们当中的大多数人，或多或少经历过从单体应用到微服务化的系统拆分和演进过程。我们按照庞大系统的业务功能和特征，将其从一个单体的大应用，逐渐地拆分成很多的子系统的协同配合完成业务功能，甚至拆分后的某些子系统服务，还可能再拆分出来更多的更细颗粒度的子系统服务。拆分后的服务之间，采用PRC调用方式的通信，也就越来越多。随之而来的，跨系统服务之间的数据一致性的问题就会越来越突出了。比如电商系统中营销活动系统的积分和优惠券的发放和扣减，比如电商系统的核心下单核心链路上，首页瀑布流，商详页，下单页等等商品价格全链路一致性等等，支撑这些业务功能的实现，往往可能需要依赖来自N个不同的业务系统服务提供的数据读写服务能力来完成。



2

如何实现服务之间的数据一致性

说到数据一致性这个话题，我们可以想到的最常用最熟悉的解决问题的方式就是事务处理了。它存在的意义是为了保证系统中所有的数据都是符合预期的，并且存在关联关系的数据之间不会产生矛盾，即数据状态一致性。事务的概念，起源于数据库，发展到今天，几乎在每一个业务系统中都会涉及到。尤其在一些大型复杂的分布式系统中，事务的概念已经不仅局限于数据库，还可以延伸为一切需要保证数据一致性的应用场景，包括但不限于数据库、事务内存、缓存、消息队列、分布式存储等等，这些都有可能会用到事务处理。


今天我们探讨的主题是服务之间数据一致性问题。当然，实际生产落地中，在不同业务背景下，具备可行性的方案也是非常多的，各有优劣和适用场景。我们从中选择一两个具体实现，聊一些相关的设计和实践。



3

几个核心名词

为了方便正在阅读本篇文章的同学对后续内容的阅读和理解，我们先对文章中使用到的几个名词的语义做一些解释和约定：
业务侧系统：指的是发起执行业务操作的一方系统服务，可以简单理解为消费方。
平台侧系统：指的是为发起执行业务操作而提供基础能力的一方系统服务，可以简单理解为服务方。
执行业务操作：指的是对数据的读写操作需要依赖多个系统服务的协同完成，业务侧系统发起，平台侧系统执行最终的数据读写操作。这样场景中就普遍存在着服务之间的数据一致性问题（备注 ：业务侧系统和平台侧系统是一个逻辑概念，并非一定要存在具体的应用服务与之对应）。
业务操作标识：指的是业务操作应该归属的业务类型或者业务场景的标识，它是平台侧系统创建并且统一管理的，然后发放给业务侧系统，在业务侧系统的服务调用平台侧系统提供服务能力的身份信息。业务标识可以设计为单层结构，也可以设计为多层结构，符合当前系统和业务的需求即可。
业务操作唯一ID：指的是某个具体业务操作在某一次或者多次重复执行的唯一性标识。生产实践中，它一般是由业务侧系统的服务自定义实现和管理的，也可以是基于平台侧系统提供有约束性质和方便管理的规则限制下，再由业务侧系统的服务自定义实现，后者是比较推荐的方式。
业务操作记录表：指的是记录业务操作的日志流水表。生产实践中，一般是由业务侧系统的服务创建并且管理。

4.1 核心思想

通过业务侧系统的服务保证数据的最终一致性，其核心思想就是业务侧系统记录下来每一次具体业务操作的执行流水日志信息，并且对没有全部成功的变更结果，触发执行数据一致性的校验核对工作。



4.2 设计原则

• 平台侧系统服务，提供支持执行业务操作的基础服务能力的接口。特别强调一点，这里是需要根据业务操作标识和业务操作唯一ID来实现接口的幂等设计。为什么我们有了唯一ID，同时还是需要有业务操作标识？因为在实际的生产实践中，在各种内因和外因的背景下，需要兼顾系统的稳定性和业务迭代的灵活性，很难做到绝对的全局性唯一ID的生成。更多时候，只需要在某个业务侧系统的内部，保证全局唯一性即可，这也是符合实际情况的系统设计。类似的解决问题的思路，在其他的系统设计场景，也是有非常高的借鉴价值的。

• 平台侧系统服务，提供执行业务操作后的结果查询接口，支持根据业务操作标识和业务操作的唯一性ID查询能力。

• 业务操作记录表，支持记录和识别业务操作的标识和每次执行的唯一ID。

• 业务侧系统服务，触发对业务操作记录表的数据一致性的检查核对工作，执行核对的方式，比如实时的同步检查核对、准实时的异步检查核对、定时任务的异步检查核对等等，为了保证自己和平台侧系统的数据最终一致性。

4.3 流程图

4.3.1 数据一致性的校验核对同步执行流程

4.3.2 数据一致性的校验核对异步核对链路

5.1 核心思想

通过平台侧系统的服务保证数据的最终一致性，核心思想是平台侧系统的每一次的数据变更，都主动地寻找业务侧系统，来确认本次数据变更结果是否符合预期。

5.2 设计的基本原则：

5.3 流程图

5.3.1 数据一致性的校验核对同步核对链路

5.3.2 数据一致性的校验核对异步核对链路

6.1 数据结构设计

接口幂等性设计，是基于业务操作的标识(这里是称之为Tag)和业务操作的唯一ID来实现的。业务操作标识的设计，可以是单层的设计，也可以是多层的设计。其中，多层的设计是为了满足业务侧系统的存在复杂并且多业务场景的诉求。业务操作的唯一ID的生成方式，可以是没有任何业务含义的自增趋势的不可重复的ID，比如MySQL的自增主键ID，分布式ID生成器等等方式，也可以是业务侧系统的某些特定的业务字段 ，比如用户的userId，订单的orderId，商品的spuId，skuId等等。在实际实践中，后者是我们比较推荐的常用方式，可以实现在不增加系统复杂度和额外依赖资源的同时，又可以和业务侧系统达到高度的契合。

6.2 状态存储设计

6.3 异常处理设计

6.4 返回结果唯一

我需要保证接口的返回的数据，再多次重复调用执行，依旧保证完全相同。我们可以基于状态机的流转控制，返回相同的状态码，也可以对一些核心业务参数做核对校验，如果不通过返回特定的异常码等等。
此外，平台侧系统的提供给基础能力接口的设计要求我们研发同学思考和考虑的更多，比如一致性延迟问题，状态机的设计，并发问题处理，接口不可用解决等等。



  6.5 延迟问题的容忍度


能否在业务侧系统服务期望的时间点，完成数据一致性的校验核对工作？若有延迟，延迟是多少？尤其是极端场景下的延迟是多少？
案例：如果使用定时任务，做数据一致性校验核对工作。比如一个周期（假设1min），还有很多数据未完成核对工作，剩余多少，以及对业务侧系统的影响。解决思路：1. 评估和设计一个合理的周期大小；2. 选择全量核对和增量核对的选择；3. 增加核对的扫描的数据范围的策略；4. 增量核对确保不丢失未核对过的数据，等等。
案例：如果使用MQ消息，我们可能面临的问题是消息堆积，消息丢失等等场景MQ问题带来的数据不一致问题。
案例：如果使用同步等待方式，是可以将数据一致性的延迟降低为0，但是系统吞吐能力和可用性等等，都是无法保证，这也是选择权衡的结果。




 6.6 基于状态机的设计

基于状态机的设计中，一定是有初始态和终态的，代表数据的核对工作，有始有终。至于中间态，可以有多个中间态，也可以是仅有一个中间态，这个和实际的需求和背景相关联的，可以灵活地控制。其中的终态，一般情况下都不会只有一种，而是有两大类，一种是成功的终态表示数据实现最终一致性，一种是失败的终态表示不因为不可抗拒的因素导致的数据不一致产生。失败的终态，也是可以设计出多种状态，根据实际需要来设计。比如多次重试从初始态到终态的耗时和处于失败态的数据核对检测工作的占比，一定程度上代表着业务侧系统对数据一致性延迟的容忍度。这应该是我们必须关注的核心指标信息。



6.7 并发问题

我们在创建一个初始化态的流水日志记录的时候，是一个MySQL的insert操作（假设你选择了MySQL作为存储），需要避免创建多条的业务操作唯一ID的记录。最简单粗暴的方式，依赖DB的联合唯一索引是可以实现的。但是需要考虑在并发比较多的时候，带来的性能和吞吐问题，甚至导致创建初始化态就失败的问题。
对于相同数据并发写的问题，我们成功执行一条insert语句，大多数情况可以满足我们业务侧系统的预期。我们可以采用加锁，排队等待，分组等待排队等等手段，限制类似场景的并发数来解决。这种方式，随着业务的发展扩张，可能会面临系统的吞吐量不足以支撑业务的问题。
解决上述的吞吐量下降的问题，我们可能又会想到采用MQ的方式来削峰填谷，因为实际生产实践中，并发写问题的往往都是一个特点 瞬时性发生的系统尖刺。采用MQ的方式，可以保证平台侧系统创建初始化态的流水日志的系统吞吐量。
在以上的基础之上，我们还是可以采用隔离拆分的方式，比如服务接口拆分层面的隔离，MQ的topic拆分的隔离等等，配合不同的限流熔断等等系统保护策略的方式以及不同的系统资源倾斜等等，解决平台侧系统的性能问题。




  6.8 需要解决不可用

熔断限流，资源隔离，多元化的降级策略等等，这些是大家都非常熟悉的系统可用性保障的手段，这部分相关的内容，就不再展开叙述了。

 

6.9 需要提供可视化和可观测

完善告警机制，比如异常状态告警，超出阈值告警等等，让相关的业务侧系统和平台侧系统同学可以快速感知到问题并且介入解决问题。
建设监控大盘，比如 MySQL，Redis，MQ，以及数据核对工作的状态的监控等等，都是需要我们去一步一步建设起来的。
定位和排查问题的工具，拆分后的系统，其系统的复杂度是指数增长的，这个方面也是非常重要的。



7

总结

在本篇文章中，阐述了两种处理数据一致性问题的解决方案，从核心思想，设计原则，系统交互流程等等做了详细的阐述，比对两种方案，各有优劣和各自的适用场景。方案一，业务侧系统来保证数据的一致性，更适用于对数据的一致性有相对比较强的耦合依赖关系的业务场景，需要依赖业务操作的执行结果做出判断，执行不同后续业务逻辑分支的执行。 案例: 同一个商品在不同修改商品信息(变更不同的字段，变更不同表的字段)的入口触发异步更新C端缓存的单品维度的商品全量缓存数据构建，变更的事务是在成功完成提交以后，方可执行本次变更对应的后续缓存构建。方案二，平台侧系统来保证数据的一致性，更适用于业务侧系统，关注点是数据的最终执行结果的业务场景，案例: 不同业务场景入口的库存扣减和库存回滚执行结果。最后，提到在生产实践过程中一些经验和解决方案的总结分享，每个点都是值得继续深入探讨。

“

扫码添加小助手微信

如有任何疑问，或想要了解更多技术资讯，请添加小助手微信：