跨系统数据一致性方案的思考（上）

欢迎将文章分享到朋友圈

1、导读

本文主要意在总结沉淀现有问题解决经验过程，整理解决跨系统数据不一致问题的经验方法。

跨系统数据一致性，比较优秀的解决方案就是微服务化，不同应用系统采用统一数据源方式，这样可以有效避免数据一致性问题。

但是我们很多系统由于历史原因或者业务缘由，导致非服务化情况下，又要采取数据一致性方案。

2、背景

业务场景简单描述如下：

上游系统（生成订单数据）

→ 业务端系统A（进行订单流程作业管理）

→ 用户端系统B（将订单作业流程映射成用户流程，供用户查看）

业务端系统A进行任何订单流程作业相关的管理操作，都需要周知到用户端B系统。示意图如下所示：

3、问题

Q：那如何实现业务端系统A-用户端系统B的跨系统数据同步呢？

4、分析及解决

阶段1：业务试点一个城市，快速上线应用

现有技术方案对比分析：

1、对于订单数据，共用业务端系统A-数据库

存在的弊端：

    1）对DB-A数据库造成查询压力；

    2）对DB-A数据库强依赖，用户端系统B处理逻辑需要配合业务端A数据结构变更随时做调整；

    3）系统间强耦合，DB-A数据库问题会直接影响业务端系统A服务可用性（SLA）及性能。

2、利用Redis Set实现简单数据同步方案

此方案主要解决：

    1）业务端A数据变动，异步通知用户端B知晓；

    2）Redis Set方式以1min为单位同步数据，过滤短时间内频繁操作订单造成的数据请求压力。

存在的弊端：

    1）Redis异常，数据丢失无恢复方案，只能针对时间等条件筛选后批量拉取修复；

    2）业务端A 直接SQL刷DB数据时，用户端B无感知。

其他工具的准备：

    对于业务端A刷数据或同步丢失造成未同步交易单情况，开发数据工具来手动恢复：可以指定订单ID，手动同步业务端A数据到用户端B，灵活快速，便于问题数据的修复。

阶段2：业务发展较快，复杂度上升，多城市落地

为了应对业务快速发展，业务订单类型和流程操作复杂度急剧上升，同时还存在拓城需求（一城一策）

原同步方式无论从性能上还是稳定性方面，都不足以应对当前的需求。

计划改造为Kafka方式进行数据同步，示例图如下：

此方案主要优势：

    1）使用kafka解耦两端系统为生产、消费端，对于高并发情况有效削峰，同时保障队列数据不丢失；

    2）消息处理效率提升。

Kafka方式传递消息体，处理性能及数据保障增强。

在实际业务中，消息量可能会随着业务量增长，由于系统消费能力有限，消息可能产生堆积，而消费端对消息有保留时长，可能会导致消息丢失，所以对核心数据消费以及消息大数据量消费需要配置kafka消息堆积监控。当出现监控报警时能及时考虑当前业务是否收到影响，并且从代码的角度是否有优化的空间，例如及时抛弃无效消息，kafka参数是否配置合理等。

假如消息生产端（业务端系统A）出现消息的阻塞，同样会影响跨系统的数据一致性，如下图所示：

上述问题主要的解决方案：

    1）监控完善（将触发kafka生产端的异步消息队列和kafka堆积消息进行监控）

    2）系统B直接监听上游数据，与系统A数据做融合（前提是确定好数据的唯一性标识）

阶段3：统一数据服务

从系统改进里程碑来看，目前仍属于冗余式存储实现，那如何从根本上解决跨系统交易单数据一致性问题呢？

消除数据不一致问题，归根结底就是要将数据源进行统一。

目前我们正计划从平台层面推进DDD领域服务划分及服务化的建设落地，后续的问题及解决经验后期再同大家进行分享。

“

关于为什么使用DDD领域服务划分？

主要是考虑DDD的Bounded context概念特别有利于识别微服务，可以作为划分服务的一种依据。正好与微服务的设计思想关键点相契合：边界和粒度。

5、总结

1、任何架构方案都是不断演进的

2、架构的目的是解决业务问题

     能够解决当前问题的架构方案，同时兼具易于扩展及维护，那就是一个优秀的架构。

3、软件设计过程中，不需要刻意去应用消息队列使用场景

     而当需要引入时，要同时考虑开发、维护成本以及对应性能的提升的性价比，否则得不偿失。