一种业务支撑系统数据一致性的解决方法

李义超+陈彤+刘委婉+吕振山+范福鑫

【摘要】 本文主要提供了一种解决业务支撑系统内部数据一致性问题的思路，首先介绍了业务支撑系统的建设背景和功能，论述了业务支撑系统随着规模扩大在分拆为多个子系统之后保证数据一致性方面的难点。然后，本文从两个方面深入分析，提供了一种解决业务支撑系统一致性难题的思路。最后，根据工程实践经验总结了数据一致性的改进方向。希望本文能够为业务支撑系统解决数据一致性问题提供一个参考思路。

【关键字】 数据一致性 业务支撑系统 分布式系统 CAP理论

一、引言

业务支撑系统一般由CRM系统和BOSS系统组成，主要实现产品管理、服务开通、计费管理、结算管理和账务管理等功能。业务支撑系统在保证业务的完整性，提升用户感知方面至关重要，业务运营支撑系统对客户提供的开户缴费报停套餐优惠计费等各种服务本质上是系统根据业务规则对各种数据进行的各种转换处理，用户的各种业务办理、信息展现均能与系统数据进行一一对应，而业务支撑系统内部数据完整和准确是保证业务支撑系统正确完整地为客户提供服务的基础。因此，业务支撑系统间数据一致性一直都是业务支撑系统建设的重点。

二、业务支撑系统的现状分析

随着业务运营支撑系统规模的扩大，业务需求也变得越来越复杂，业务支撑系统会不断进行拆分。例如，一般业务支撑系统至少包括产品管理、服务开通、计费批价、结算管理、账务管理等单体模块，当系统规模较小时，所有的单体模块都集成为一个系统，所有单体模块的数据存储在一个数据库系统中，由数据库系统保证各单体模块数据的一致性。当各单体模块拆分之后，每个单体模块独立建设成单独的子系统，各子系统的数据持久层保持独立设计，没有了数据库对数据一致性的保证，各子系统之间的数据不一致性问题变得非常突出。例如，在服务开通系统入库的用户订购数据，需要与计费批价系统数据保持一致，否则易造成批价错误，直接影响运营商的收入损失或者用户体验感知。此外，运营支撑系统由于历史原因，每个子系统倾向于独立建设，造成了各子系统之间设计架构不透明，更加造成了每個子系统间保持数据一致性的难度。

在数据一致性理论中，一致性可以分为强一致性、弱一致性和最终一致性，强一致性是指当一个系统数据更新完毕之后，其他后续系统数据随即完成更新；弱一致性指当前系统数据更新完毕后，后续系统并不保证立即更新数据，也无法保证多久可以更新；最终一致性是弱一致性的一种特例，保证最终各系统的数据一致。在分布式系统中存在CAP理论，即Consistency（一致性），保证各系统所有数据变动都是同步更新；Availability（可用性），保证优系统具有优异的响应性能；Partition tolerance（分区容错性） ，保证系统的可靠性，CAP理论证明了任何分布式系统只可同时满足二点，没法三者兼顾。高可用、数据一致是大多数系统设计的基本目标，但是随着系统规模的扩大，分区最终是无法避免，业务支撑系统也不例外。常用的分布式系统为保持系统数据强一致通常采用分布式事务控制的方法，即通过事务的回滚与提交保证各子系统的数据完全一致。但是，保持系统强一致性，会牺牲系统可用性，因为，为保持系统强一致性需要在各系统之间进行数据同步，这样会导致同步时间无限延长，使业务功能操作的耗时达到不可接受的程度。此外，由于各子系统独立建设，系统设计架构不透明，实际工程中很难在数据持久层通过事务控制的方式达到强一致性。

三、业务支撑系统内部数据一致性解决方案

由上文所述，分布式系统无法同时兼顾可用性与一致性，在实际工程中，业务支撑系统为保证系统可用性，往往放弃系统强一致性，追求系统最终一致性。本文提供了一个解决方案，从两个维度设计保证系统的最终一致性。

3.1 业务分布式控制

由于业务支撑系统下面各子系统建设的分离导致无法在数据持久层进行事务控制，可以在业务层面模拟分布式事务对业务订购进行事务控制。例如，下面的一个业务订购操作需要由子系统A、B、C、D、E协作完成，子系统A向子系统B发起业务订购操作，子系统B将该业务订购从业务层面分解为子事务A、B、C，分别由子系统C、D、E完成，各子系统处理完相应的子事务后，将处理结果同步给子系统B。最后，各子事务完成均成功提交后，由子系统B提交处理结果给业务发起方（即子系统A），由子系统A完成竣工操作，如果其中一个或多个子事务没有成功提交，由子系统B发起回滚操作，该笔业务订购处理失败，由人工干预介入处理。

通过业务层面上模拟分布式事务的处理机制，即保证了各子系统的数据一致，同时又避免了系统耗时严重造成系统不可用。

3.2 数据一致性稽核

业务支撑系统的数据不一致的部分原因是人为修改数据造成的，因此还需要额外的处理措施减少各子系统的数据差异。通过开展数据一致性事后稽核可以达到该目的，定义各子系统的关键数据字段和数据比对规则，定期开展数据一致性的全量和增量比对，发现各系统的差异数据，分析差异原因，开展数据修复工作。

四、结论

根据本文的解决思路在物联网业务支撑系统中进行了工程实践，取得了良好的效果。根据运营集中化建设的原则，物联网业务支撑系统承载全网31省物联网业务，该系统在运营域主要分为运营管理系统（主要负责运营数据展现和外部能力提供）、服务支撑系统（主要负责服务开通和产品统一管理）和内容计费系统（主要负责话单计费结算和账务管理）。

在业务规范设计时，模拟分布式事务的处理机制，保证三方系统正常提交后方进行竣工操作，已保证数据的完整性和一致性。通过每月例行的在线数据一致性稽核发现，三方系统的数据一致率能够达到99%以上。

同时，从实际工程中，总结了一些深层次问题，在后续的工作中持续改进数据一致性工作。其一，完善数据一致性稽核接口，细化数据一致性稽核的粒度，提高数据比对优先级，开展每日的数据对账；其二，在数据持久层实现数据一致性问题，在系统设计时，在数据持久层设计各系统间的数据同步接口，使业务操作在入库阶段完成各子系统的同步操作，在更细的粒度保证各系统的数据一致性。

参 考 文 献

[1] 顾怀恩 . 业务支撑系统数据一致性研究 [J]. 电信工程技术与标准化，2009（08）：67-70.

[2] 张立成，杨敬巍，褚 尧，王敬尧 . 论业务支撑系统数据一致性的保障机制 [J]. 通讯世界，2015（23）：2-4.

[3] 左正 . 保证分布式系统数据一致性的6种方案 [网页博客]. http：//www.cnblogs.com/soundcode/p/5590710.html 2016-06-16 13：33