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、软件设计过程中，不需要刻意去应用消息队列使用场景
而当需要引入时，要同时考虑开发、维护成本以及对应性能的提升的性价比，否则得不偿失。
