2019-2020 年，随着计费、佣金、结算项目的相继上线，分布式内存数据库(后述 ZMDB)承担了计费、账务、余额、场景三、佣金、结算等各个系统的核心数据，在各业务项目中占据着越来越重要的作用。

ZMDB 充分发挥分布式的特性，作为公共平台组件，为业务实现数据去 O、资源整合、性能提升、持续在线等各种优势，助力各接入的业务单元腾飞。19 年随着重庆、甘肃、新疆三省 BSS3.0 上线，最后一个 TT 内存库的堡垒——余额库，也被 ZMDB 完全替代，并助力大量业务(余额缴费、查询等场景三及接口类业务)实现功能、性能的飞跃。

ZMDB 在部分省余额库数据支撑概况

ZMDB 是一个支持 SQL92 标准的、共享内存实现的关系型数据库，在具有完整的 SQL 处理、事务控制、行级锁上，还支持水平分片、分布式事务处理、主机故障自动切换等功能。此外，ZMDB 还为业务提供了标准的 JDBC/ODBC 访问接口，实现了业务从传统关系型数据库(指 ORACLE\INFORMIX\MYSQL 等以文件存储为核心的物理数据库)到 ZMDB 的快速迁移。ZMDB 在数据关系表示、事务特性、SQL 标准上与传统关系型数据库的平台标准高度一致，为高速发展的各类热点数据访问场景提供了一种更优的选择。

内存数据库本质上是与传统数据库和缓存的互补，它的优势在于既完美实现了基于关系型数据库的 SQL 标准、事务特性、数据关系表达，又实现了内存操作微秒级的高性能指标，为当前电信业务脱离传统数据库的束缚提供了一种更优的解决方案。

内存数据库架构提升迫在眉睫

在计费 2.8 时代，内存数据库实例主要是部署在内存较大的单个主机上(一般是 AIX 机器)，提供业务数据直连访问的能力。在这样的架构下，随着业务规模和数据的不断扩展，就需要增加大量主机冗余存储数据。临近 3.0 时代，当前的架构模式越来越难以支撑海量增长的数据和应用，为了有效的整合资源、建造可容纳上万链接的分布式集群，ZMDB 的分布式架构提升势在必行。

作为计费核心的关系型数据库，为了对业务系统的高效支撑，ZMDB 在进行分布式架构演进时必然面临诸多方面的考虑：

首先，在实现分布式框架后，应用如何透明接入 ZMDB 是首当其冲需要考虑的问题。必须保证业务在最少改造的前提下，实现数据分片访问、分布式事务、分布式锁控制等核心功能，否则现网核心业务中(比如批价、合账)的大量事务一致性需求就没法满足。随之带来的，将是整个计费系统的准确性和稳定性的下降，对其他接入 ZMDB 的系统(佣金、结算、OCS 等)来说也存在不小的风险。

其次，在将平台从 AIX 迁移到 X86 上后，操作系统的稳定性也随之下降，主机随时有可能出现宕机的情况。而在计费系统中，大量场景三业务(余额充值、查询等关键接口)也是访问内存库的，这些业务不仅涉及集团考核，也影响着众多电信用户的体验感知，不允许出任何差错。因此，实现 ZMDB 的高可用，在单点故障时可以实现业务无感知的自动切换，也是重中之重的工作。

最后，如何弥补系统从直连访问切换到远程访问所带来的时延影响，也是我们要解决的关键问题。MDB 本地访问单条记录的时延约 1 微秒，而 1 次网络交互带来的时延就已经有上百微秒，业务切换到远程访问后单笔交易性能下降近百倍。当然，随着分布式系统带来的链接数扩容，大部分业务可以通过增加并发处理流程，保证系统整体 TPS 提升。但是，对于某些严格串行执行的业务，比如计费出账相关的部分业务流程(日租日优惠、下账等)，就没办法通过简单的并发拆分提升性能，最终会导致出账性能急剧下降，无法实现集团 1 号 8 点出账的规范要求。

综上所述，进入 BSS3.0 阶段，如何针对 MDB 的实例数据进行资源整合，适应业务规模和数据的不断扩展，并保证对业务系统的高性能、高可靠、高稳定支撑，成为 MDB 演进道路上迫在眉睫的重点工作。

分布式架构提升的路该往哪走

MDB 的分布式架构演进过程，在功能上面临跨节点分布式事务、分布式死锁的挑战；在性能上面临从本地直连访问切换到远程访问带来的时延提升挑战；在高可用上面临主备数据一致性、在线切换恢复的挑战。起初，这些问题我们准备直接按照行业标准进行，完全参考业内开源分布式数据库解决方案，但是经过方案的预研和对比，发现照搬的效果差强人意。

为什么现成的不能直接用，存在哪些问题呢？

首先，计费后台核心业务逻辑大多是由 C++实现的，通过公共接口实现对 MDB、ORACLE、INFORMIX、TT 等数据库的访问，相关协议也都支持 SQL 绑定变量。在计费 3.0 改造过程中，保持原有接口的可用性，可以让业务具备在多种数据库下动态切换的能力；反之，则需要重新进行大规模的接口和协议改造。开源的数据库访问接口与协议大多是基于 JDBC 和 MYSQL 协议演进而来，在功能、性能、及改造量上都没法满足计费需求。同时，其中大多是以动态 SQL 的形式实现数据绑定，与计费使用绑定变量的形式有着本质的差异，在安全性、可靠性，以及代码适配程度上都有着不同程度的影响。一旦直接采用开源方案，将导致整个系统从业务层、数据访问层再到协议层的全面重构，这个代价是巨大的。

计费 C++业务数据库访问架构

其次，开源的分布式协议在解决分布式事务、分布式死锁等问题上，依赖于所引入的控制节点，而这些节点无一例外需要通过牺牲系统整体 TPS 为代价。此外，分布式事务的处理难度不仅是在保证不同节点的事务一致性上，而且还会在并发操作的场景下，在网络时延和 CPU 切换的共同作用下，触发难以预警的分布式死锁。面临国内电信行业复杂的数据关系(三户模型、产品实例关系等)，这些问题是必然会发生，也必须要解决的。

分布式死锁问题时序概念图

最后，在性能上要达到微秒级、在高可用切换上要达到秒级、单节点 TPS 要达到十万级，大部分开源架构都没法满足这些硬性的指标要求。

综上所述，在我们经过一段时间的预研、学习、实践后，明确得出 ZMDB 的分布式架构演进之路，必须以创新自研为出发点、以借鉴学习为方式、以结果为导向，并紧贴国内业务现状和诉求，一步一个脚印，踏踏实实的走出来。

自研分布式框架解决的关键问题

应用如何透明接入：多层动态分布式协议

ZMDB 多层动态分布式协议

集群统筹层

• 统一封装数据访问接口，包括客户资料访问接口、实时帐单访问接口、拣重存档访问接口、规则数据访问接口、清单数据访问接口等，实现计费 2.8 迁移到 3.0 的所有 C++、JAVA 应用零改造接入 ZMDB。

• 完成对实例集群的节点拓扑、分片信息进行统筹管理。

节点分管层

• 动态完成节点选择、链接控制、节点状态控制、事务控制、结果集合并，并实现对业务透明的分布式内存数据库访问。

• 增加业务跨节点操作的多种模式，实现动态调配业务串行、并行访问节点，彻底解决分布式死锁问题。

数据交互层

完美对接用户资料数据、累积量数据、余额数据、账单数据、信控数据、流控数据、捡重数据等多钟数据类型。通过自定义的协议进行访问控制，实现单实例百亿级数据高速访问，平均单条访问时延生产约 120 微秒。

保证系统高在线率：节点故障自动切换

ZMDB 的分布式架构通过抽象出集群中的关键节点属性，构造集群状态切换的状态机，实现对所有正常、异常下的节点状态进行精确维护。集群运行期间，每个节点都区分成主读节点和读写节点，而状态的维护变更由管理节点统一进行，直接避免了分布式系统中的脑裂问题。各节点的状态拓扑，在每个 DBC 接口处也进行了维护，由上述分布式协议确认集群拓扑并进行重试、重连。目前，ZMDB 已经具备配置 1 秒内检测主备故障，并在线自动切换的能力，切换期间应用完全无感知。

低时延的业务诉求：本地高速缓存

ZMDB 本地高速缓存功能架构

部分业务对于数据访问时延有着较高要求，比如账期类的业务应用(日租日优惠等)，这些业务具有扫描大量重复数据的诉求。ZMDB 助力于这样的业务场景，提供了本地高速缓存，以较少的本地内存存储，实现业务通过 DBC 接口无感知接入缓存和切换集群查询，并达到 1 微秒级的访问性能。此外，基于我们提出的《一种基于 SQL 特征的改进数据库高速缓存异步刷新的方法》，缓存数据也可以准时的与集群进行同步。目前，使用本地高速缓存的业务处理性能均可以上升数倍，在各种对性能苛刻的业务场景下有着广泛应用。

担当使命，接过时代的接力棒

2019 年下半年，随着 ZMDB 在计费、佣金、结算、OCS 等项目的广泛应用，我们不仅实现所有使用单机 MDB 的项目成功迁移至 ZMDB，还新增了对场景三、余额、佣金、结算等项目的高度支持。ZMDB 在业务承载力、系统稳定性、系统高可用、集群性能上表现卓越，在电信行业的场景上承担着越来越重要的角色：

访问性能有保障：场景三(余额查询、套餐余量查询、话费充值等)迁入 ZMDB 提效支撑，特别是甘肃、新疆、重庆等省份余额数据使用 ZMDB 替换 TT，极大的优化了业务访问性能，保障了各省集团考核名列前茅；出账(累积量初始化、下账、批冲等)基于 ZMDB 效率优化，助力新疆在全国出账比武勇夺第一。此外，ZMDB 也与业内广泛使用的 TT 数据库进行对标，访问性能在业内保持领先水平。

ZMDB 与 TT 性能对标(单链接)

业务支撑有经验：ZMDB 始终坚持易接入、高性能、可扩展的方式拥抱各类业务，为业务的数据去 O、性能优化、持续在线提供强有力的解决方案。目前 ZMDB 已经在计费、账务、OCS、佣金、结算等几十个项目中承载了各种类型的海量关键数据，单实例可容纳五千张表和上万链接，大量核心数据(用户资料、用户余额、用户累积量、用户账单等)也已完全基于 ZMDB 稳定性运行。

ZMDB 在部分计费省份上支撑的用户及数据概况

系统稳定有成绩：ZMDB 作用在各项目后，对于生产中各类单点故障(主机宕机、网络中断、更换硬件)，目前均已做到高可用支撑。通过系统的故障在线切换方案，为业务提供高度在线不间断的可靠服务，并配合客户进行多次验证，得到广泛认可。目前大部分实例均已接近一年连续提供高强度的业务支撑，部分关键实例(余额、累积量等)在上线至今也均实现系统故障率为零的成绩。

ZMDB 在完成自研的分布式架构提升后交出了一份令人认可的答卷，我们在系统架构不断优化的过程中也获益良多。分布式内存数据库为 paas 平台在数据库方向的遗漏做了完美的补充和阐释，应用的场景也越来越广泛。而当前的架构提升只是我们拥抱未来的第一步，如何让 ZMDB 具备助力更多业务场景的能力，具备承接 5G 时代的要求，是我们接下来首当其冲要考虑的核心问题。

目前，我们已经同步开展覆盖更多复杂 SQL 类型的预研工作，通过与分布式数据库进行更深层次的对标，探索并实现 ZMDB 更多的应用场景。同时，随着基础设施的不断升级，我们也会在可扩展、易运维的方向持续进行优化，寻求突破。只有不断持续迭代，不断学习和追求更有益于生产的技术，才能让我们有更好的机会把握未来的无限机遇。