千日稳定守护，金仓数据库赋能北京一卡通斩获鼎信杯奖项

千日稳定守护，金仓数据库赋能北京一卡通斩获鼎信杯奖项

金仓数据库作为拥有自主知识产权的国产通用关系型数据库管理系统，已广泛应用于交通、政务、金融等关键行业核心系统建设。近三年来，该数据库持续为北京一卡通数字支付系统提供稳定支撑，从北京早晚高峰的公交地铁、商超消费，到全国330余座城市的公共交通、民生出行消费的各类场景背后，都有金仓数据库的技术护航。凭借千日稳定运行的优异表现，让自主可控的国产数据底座深度融入民生服务的每个细节。近日，由中国软件评测中心主办的第四届"鼎信杯"大赛获奖名单正式公布，北京市政交通一卡通支付有限公司（以下简称"北京一卡通"）凭借面向城市出行的数字支付核心系统数据库信创迁移改造与架构升级创新实践案例，成功斩获金融赛道金鼎实践奖。

一、"交通+消费"：辐射全国的基础设施

公开数据显示，作为全国规模领先的交通一卡通公司，其服务范围早已不局限于北京，而是形成了立足北京、覆盖京津冀、辐射全国的服务格局，涉及城市交通、商业消费、智慧城市等多个领域。一卡通系统已经成为和市民联系最紧密的基础设施之一，其运行稳定性直接关系广大市民群众的出行与消费体验，搭建自主可控的国产基础平台成为必然选择。

2023年，北京一卡通启动清结算系统升级改造，数据库作为数据管理和存储的基石，在升级改造中扮演了重要角色，面临诸多挑战：

• 市政交通是城市运行的核心支撑系统，业务运行不容中断；
• 一卡通系统涉及业务种类繁多，业务逻辑复杂；
• 高峰时期需支撑千万级数据处理，夜间还需完成大规模清分结算，对数据库的高并发、高性能、高可用、高安全提出极致要求。

经过层层技术筛选及现场实际测试表现，电科金仓凭借出色的产品力、双轨并行平滑迁移方案和本地化团队带来的优质服务，和北京一卡通达成合作。

二、金仓赋能：千日稳跑打造行业标杆

面对北京一卡通项目的严苛要求，电科金仓凭借产品+方案+服务的全栈能力让这场高难度替代平稳落地。在项目实施过程中，电科金仓和一卡通共同形成了"迁移前评估验证、迁移中平滑同步、上线阶段双轨并行"的实施方法，有效保障了核心业务平稳切换和性能提升。

2.1 原生兼容非信创系统

金仓数据库原生兼容原有非信创异构数据库及开发框架，同时项目团队针对非信创数据库生态开展了深度调研与反向适配，对典型功能SQL和关键业务链路进行定向优化，在不修改应用的前提下，大幅提升运维人员的便捷易用性体验，确保业务系统的稳定性和应用服务的连续性。

2.2 双轨并行平滑迁移

针对大存量数据和短割接窗口的矛盾，电科金仓团队创新采用"KFS+KDTS"技术组合拳，将原数据库的历史数据和增量数据导入金仓数据库，在保障数据一致性的前提下，实现TB级数据在短割接窗口内完成迁移，显著降低停机时间，对同类型数据库国产化替代具有普遍参考意义。

三、项目背景：响应国家信创政策，实现核心系统自主可控

北京市政交通一卡通有限公司于2000年10月经市长办公会批准成立，负责交通智能卡的制作、发售、应用和结算业务。清结算系统是管理平台及核心系统，承担制作、发行、清分结算、对账、异常申诉业务及相关处理、数据同步、查询等功能。北京一卡通广泛应用于北京地区公交、地铁公共交通领域，P+R停车场，超市、便利店、快餐店、蛋糕房，市政缴费、福利彩票、自动售货机等多个场景。

为响应国家信创政策要求，一卡通公司对清结算系统进行改造升级，数据库作为数据管理和存储的基石，在本次改造升级中扮演重要的角色，希望通过数据库数字化升级及创新技术应用，为企业提供高效、可靠和安全的数据管理解决方案。

在数据库品牌选型过程中，是通过现场大数据量的迁移验证，高可用验证、性能比测等，基于现场实际测试表现，金仓在迁移阶段的平滑迁移方案优势明显，最终选择金仓数据库作为入围品牌。

3.1 项目重点难点

1. TB级数据量：原业务数据库涉及TB级数据、一千多张表；如何在2小时的割接窗口内完成成大数据量的不停机平滑迁移，既不影响业务下如何保障迁移一致性？
2. 千万级事务：涉及城市交通、商业消费、市政服务、智慧城市等多个领域，早高峰3小时支撑千万级数据库事务处理，夜间2小时批量处理千万级数据库事务处理、支持日最大交易处理量千万级交易交易量。
3. 新老系统迁移并存：新老业务系统迁移和新开发并存，如何保证业务系统数据的一致性；如何实现快速迁移项目适配开发、最大限度降低开发成本，业务为自研系统，对Oracle高度依赖，如何实现快速兼容、快速适配。
4. 平稳、零割接：不管新系统、还是老系统，不允许影响业务，如何保证新旧系统更替、系统稳定过渡，同时具备低成本容灾。

四、项目实施：分阶段推进，保障核心业务平稳切换

4.1 项目建设思路

系统现状	需求分析	金仓方案
大数据量迁移：原系统存储数据TB级，如何在2小时的割接窗口内完成不停机平滑迁移？	迁移阶段：做原数据库迁移评估及应用适配测试评估；存量数据迁移效率及割接窗口工作量评估；增量数据数据同步+数据比对一致性评估	数据库部署方案：基于金仓数据库构建同城容灾集群，网络A中为一主一备，另外的一个备机在网络B中
高并发：早高峰3小时支撑千万级数据库事务，夜间2小时批量处理千万级事务	验证阶段：针对原Oracle典型业务时段负载做对比测试；评估负载报告及典型高能SQL，做定向优化；逐步增加全业务负载、高压压力测试，稳定性测试	大数据量平滑迁移方案：采用金仓异构数据同步产品KFS + 金仓数据迁移工具KDTS的组合方案，保障在2小时的割接窗口内完成平滑迁移
高并发：构建混合并发BS架构+CS架构升级中，保留原系统的逻辑，但采用微服务的方式进行了拆分，百余个微服务同时访问数据库，存在大量并发访问的现象	并行上线：实现新环境支撑业务数，原Oracle并行运行，规避风险；规划同城容灾节点，实现低成本容灾	性能验证方案：针对当前业务支撑环境，分别从样从上午6:30到9:30和凌晨2:30到4:30的数据库服务器负载，进行100%和300%的压力进行压测分析，保障新的部署方案要能完全承托之前的压力
		双轨并行上线方案：基于金仓数据KFS + KFS-Oracle，实现基于异构数据同步的双轨并行；风险可控

4.2 项目实施里程碑

• 2023年3月：测试双轨并行，验证上线前的割接流程（选型测试阶段）
• 2023年4月：针对KFS性能问题优化，解决原端解析慢、目的端入库等性能问题（性能验证阶段）
• 2023年5月：演练双轨迁移、同步，解决迁移同步的问题（准备上线阶段）
• 2023年6月：分析解决KFS新版本带来增量数据同步的问题（上线测试阶段）
• 2023年7月：全量+增量同步数据及性能验证（上线测试阶段）
• 2023年8月：分析解决KES产品JDBC问题，导致某些业务表现出数据不一致情况（试运行阶段）
• 2023年9月：全量+增量同步验证（正式运行阶段）
• 2023年10月：上线保障，优化及维护（运行维护阶段）

4.3 项目迁移及上线方案

• 柔性迁移方案：对源库无影响、无侵入，通过原Oracle数据库部署架构与金仓数据库部署架构的平滑过渡，实现数据的无缝迁移。
• 双轨并行上线：风险可控，通过应用侧实现双轨并行，新老应用双轨运行，分阶段压测、千万笔交易、一致性校验、全流程风险可控，有效控制切换风险。

五、项目总结：千日稳定运行，赋能数字支付新生态

5.1 一卡通系统业务上线过程主要问题及解决情况

项目过程中主要问题数40余个（截至2023-10上线），主要分为优化改进类问题、功能、性能、业务需求类问题、业务兼容性类问题。在问题解决时效性上，金仓研发团队能够及时、重点问题平均有解决问题的能力，重点问题平均1-2周内能够较快解决，保障了业务系统改造及上线要求。

问题一：高并发访问压力

• 难点说明：原单业务同时进行微服务拆分之后，共百余个微服务同时访问数据库，存在大量并发访问的现象，造成资源争抢，业务事务容易被堵。
• 带来的问题：不同微服务的违章/对账文件/批量对账上报数据造成业务崩溃，导致人工处理；不同微服务语句造成锁回滚现象，直接导致机子停止处理业务；重卡导致语句执行时间超长，业务卡脖子，业务中断。
• 金仓解决方案：产品优化，增加资源使用限制、并行技术、vacuum参数的优化，配合业务进行了批业务的梳理，各个微服务之间避开分流到节点；提供驻场运行监测服务，部分只业务分流到读节点。

问题二：网络环境复杂

• 难点说明：为了安全考虑，进行了跨网部署应用和数据库，全部虚拟机都在华为云上，网络中间层过多；微服务带来的配置困难。
• 带来的问题：带宽不够时，导致业务系统将错；转发idbc心跳线路时，导致业务系统将错。
• 金仓解决方案：产品优化，重新调整idbc心跳机制，增加网络容忍性；在合理化重新调整时，调整超时机制，增加网络各态性能；金仓提供24小时驻场监控工具服务，协助排查系统故障情况。

问题三：业务耦合度高

• 难点说明：一点系统在进行微服务拆分之后，也将原来的批处理改为颗粒度更低的微批，部分业务高峰期存在耦合，业务之间连续产生业务分层。
• 带来的问题：单个批处理的错误会导致业务人工介入；单个批处理的错误会导致业务人工介入。
• 金仓解决方案：金仓应用侧针对方案中的慢语句，优化批量处理方式，优化入库的性能；配合应用侧，制定了完善的异常处理方案，一旦出现冲突，人工介入排障。

六、应用实践：打造可复制的国产化替代模式

6.1 案例简介

数字支付系统是公司自主研发的面向企业和用户的数字化平台，涵盖TSM、一码通乘、支付、用户、清结算五大核心模块。其中，清结算模块作为交通卡业务资金流转和对账的核心环节，对系统的高并发处理能力、数据一致性和安全性有着极高要求。

在国产化替代的大背景下，公司启动了清结算系统数据库改造项目，将底层数据库由ORACLE迁移至金仓数据库。这一改造是整个数字支付系统信创化的重要组成部分。

• 原系统：采用ORACLE 11G 2节点RAC集群+ORACLE RAC 2节点同城容灾集群，10TB以上。
• 新系统：采用金仓数据库管理系统KES 2节点读写分离集群+1节点同城容灾。

改造过程中，团队重点解决了三类问题：

1. 技术适配差异：针对ORACLE与金仓在数据类型、存储过程等方面的不同，建立功能映射清单并逐条改造。
2. 性能调优挑战：在高并发交易和单行频繁更新场景中，联合厂商进行索引优化与参数调整，显著提升事务处理效率。
3. 系统稳定衔接：通过接口改造和专项监控机制，保障支付与清结算业务在迁移过程中的连续性与稳定性。

6.2 技术先进性

1. 数据库国产化改造，低难度平滑迁移：在清结算系统国产化改造过程中，成功实现了数据库从ORACLE向金仓数据库的替换，确保了资金结算、对账等关键业务的连续性。系统研发团队针对ORACLE与金仓在数据类型、存储过程、函数机制等方面的差异，快速完成了适配改造，保证了业务系统的兼容性与稳定性。在迁移过程中充分利用金仓数据库的多语法兼容与扩展能力，实现了低难度迁移与高效适配，100%兼容主流数据库常用语法，降低了系统重构成本。
2. 核心业务平稳切换，性能与可靠性提升：在国产化替代过程中，通过双轨并行的方式，实现了核心业务的平稳切换，系统性能和可靠性得到显著提升。

6.3 应用实践

北京市政一卡通清结算系统数据库国产化替换的成功实施，充分验证了"低成本、低难度、低风险平滑迁移方案"在该领域得到落地应用，为后续各领域业务系统替换，提供了实践经验。

业务介绍：

1. 系统支撑：实现十余TB以上大数据量迁移、完成每日同步增量日志>百G、首次实现日交易事务量>千万笔，小时级批处理>百万事务。
2. 系统架构：搭建全国产2节点主备集群+1节点同城容灾、7*24小时稳定运行，容灾故障秒级切换。
3. 数据迁移：采用低成本、低难度、低风险平滑迁移方案，完成存量十余TB数据快速迁移，迁移耗时<3天，KFS增量数据快速同步、数据一致性自动比对。
4. 性能测试：重点业务场景单条复杂SQL毫秒级响应；重点场景1000、2000、3000并发压力测试。

应用成效：

1. 首创实现国外主流异构数据库低成本兼容方案，适用于各类业务系统不同数据库的低成本替换。
2. 标准化迁移工具、实时增量同步工具，形成成熟迁移方案，实现原始系统全量数据的快速搬迁和实时比对，大幅降低迁移成本。

在应用适配方面，部分原有中间件与ORACLE的绑定较深，迁移后产生兼容性问题。我们通过改造接口层，增加适配组件，使系统能够稳定对接金仓数据库。同时，建立了专项监控机制，实时监测事务延迟和异常，提升运维保障能力。

通过此次改造，我们积累了"先比对差异、再分步迁移、最后联合调优"的实施经验，为后续集团内其他支付、结算类系统的国产化替代提供了可复制的模式，也为数字支付体系在安全合规、可控可管方面打下了坚实基础。

七、总结（核心价值、最佳应用）

北京市政一卡通清结算系统数据库国产化替换的成功实施，印证了金仓数据库对北京市政一卡通业务系统的支撑能力，印证了金仓数据库在不同应用场景下的稳定性以及各种开发框架在不同应用场景下的兼容性，印证了金仓数据库在高并发场景下的迁移方案，低难度、低成本、低风险、低业务影响的迁移方案。

项目的成功实施：

• 打破了行业数据库对国外产品的依赖；
• 打破了行业数据库对国外产品的依赖；
• 供了宝贵的方法学和实施经验；
• 为北京市政一卡通各应用提供了积极稳妥的推进自主可控数据库的应用提供了可操作性；
• 为行业数据库的应用提供了可操作性。