信用卡核心系统性能提升研究与实践

上海浦东发展银行信息科技部开发中心 林 朋

随着信用卡业务发展，信用卡业务已经突破了传统的服务边界，变得无处不在，各种业务混合场景融合，这对于信用卡核心系统的性能要求越来越高。

浦发银行信用卡核心系统数据库集中部署在IBM小型机架构，在信用卡业务发展初期，基本可以满足业务需求，但是随着信用卡业务发展，信用卡业务越来越呈现出高并发、灵活性等特点，单实例，集中存储数据库的弊端越发明显，性能问题日益凸显。主要瓶颈点如下：

数据库采用单实例部署，在交易高峰期时，数据读取和更新对于存储压力非常大，特别是数据库REDO日志单点的性能压力成为最大的瓶颈。

EMC存储虽然可以做到高可用和高稳定性，但是由于是集中存储，在系统高峰期时，存储性能下降严重，平均IO读写由1ms，延迟到5ms以上，造成了每笔交易耗时拉长到5倍。

为了提升系统处理能力，强化信息安全，构建更为灵活的信用卡核心系统。浦发银行根据信用卡核心系统现状，2019年启动实施信用卡核心系统性能提升项目，以提高系统性能为目标，能够适应大规模业务增长，实现多场景、高压力的、高聚合的和稳定的信用卡核心系统。

1 信用卡核心系统全闪存存储设计

信用卡核心系统以华为全闪存产品，替换了EMC存储，将数据库RAC架构部署于全闪存储环境，率先采用高端全闪存和NOF+方案等技术，从前端协议到后端SSD盘全部采用NVMe承载，打破毫秒级存储响应速度的极限。

每个物理端口与引擎内四控制器直连。引擎内4控全对称互引擎间通过共享卡交换互联。SSD智能框通过后端共享卡连接到8个控制器（2引擎）。

支持Active-Active访问，业务均衡分布在前端链路上。采用DHT算法将LUN按固定大小均匀打散到所有控制器。直接将LUN的固定大小分片发送给目标控制器，降低时延。主机请求可在任意控制器写入Cache缓存，任意控制器智能读缓存可预取所有LUN的数据和元数据，提升Cache命中率。数据在落盘之前进一步被切分为8K，均匀打散到各个盘片上。RAID2.0技术确保空间的均衡性，以及重构的快速性。

优化数据存储的全流程，创新在“传-算-智-存-管”的关键路径上进行端到端的加速。同时，打破现有业务的壁垒。该存储架构满足了信用卡系统多个模块在业务高峰期时段的高并发、低时延、高达数十万IOPS峰值的业务响应诉求，实现多个模块间数据资源共享和高效协作，提升交易能力，存储性能提升3.5倍以上。

2 信用卡核心数据库设计（如图1）

图1 信用卡核心数据库设计

信用卡核心数据库采用ORACLE RAC集群架构，按照两地三中心部署，上海主中心部署2个集群，合肥部署2个集群。4个集群中默认上海其中一个集群为主库，其他三个集群为ADG库，为了避免ADG库影响主库，4个集群之间采用最大性能模式，通过联机日志同步。两地两中心4个集群可以同时对外提供服务。

为了保证RPO为零，即保证在同中心的主库和ADG库发生灾难时，数据零丢失，信用卡核心数据库在上海同城中心搭建了FAR SYNC数据库，在每次数据库更新时，都需要完成同城双写成功后才能提交，更新联机日志，保证了同城双中心的数据一致性。

每个集群数据库实例各自有一套数据文件、控制文件和联机日志，部署在全闪存储上。每个集群有两个数据节点，共享一套数据文件，数据节点间组成私网，每个节点通过25Gb网卡互联，以减少GC，实现节点间内存数据快速同步。

在使用25Gb网卡的情况下，单台配置为72core756GB的X86服务器（cpu型号为6154），在RAC环境下，搭配全闪存储，上海一主一备2个集群，合肥一主一备2个集群，总共需要8台机器。

考虑到在性能测试中碰到的问题，信用卡发卡的数据库服务器的网卡对于tcp的小包的处理能里要求较高，因此业务网卡拟配置4个25Gb网口，另外adg配置2个25Gb网口，备份配置2个25Gb网口，心跳配置2个25Gb网口，考虑网卡的高可用，总共需要6块双口25Gb的网口。配置2块双口16Gb的卡。本次测试中数据库使用的内存约为400GB，考虑到生产环境为应对突发交易，进一步提升性能，需要将一部分表缓存在recycle_cache中，本次投产需要缓存的表的数据量共337G。

3 信用卡核心应用多活设计

信用卡核心应用采用两地双活部署，主中心处理可写交易，异地中心处理只读交易。信用卡前置系统配合改造，将非本地的交易通过前置系统内部路由到对端分中心后转发给核心系统。

信用卡前置系统对于每个服务提供方会设定一个分中心标识，用于标识该提供方是运行在上海分中心还是合肥分中心。对于需要在合肥运行的交易设定单独的虚拟提供方（等同于服务提供方），其分中心标识定义为合肥分中心。当一笔交易进来后，会判断交易的服务提供方是否属于本地分中心，如果属于则直接路由给本地后端系统，如果不属于，则判断对方分中心的前置系统和后端系统是否都正常运行，如果存在一个不正常，则仍路由给本地后端系统，如果都正常运行，则将交易的数据进行压缩并计算MAC（MAC Key单独申请一个），通过短链的方式传输到对方分中心，由对方分中心发送给后端系统，再原路返回。

前置系统对对端分中心前置系统和后端系统进行固定频率探测，探测是否运行正常，信用卡核心系统提供一个探测交易用于探测。

4 核心数据库高可用设计

信用卡核心系统数据库由小机切换到X86后，X86机器稳定性较小机要低，需要考虑X86机器突然宕机，导致数据库由主库切换到同中心ADG或切换到异地ADG，信用卡核心系统应用需要同步进行切换数据库。根据业务需求，信用卡核心数据库和应用在发生故障时，需要自动完成切换。

（1）在发卡数据库中建立数据库路由表，每台应用主机一条记录，登记可写库和只读库。

（2）发卡每笔交易的sql较多，与数据库多次交互，考虑到网络延时，本地应用只连本地的数据库，即上海应用只连上海数据库，合肥应用只连接合肥数据库。

（3）在每台应用服务器部署轮询脚本，检查读写库和只读库是否正常。上海的应用服务器检查MDB和ADG，根据可读写属性，与数据库路由配置表比较，如果与当前配置不同，则更新路由配置表，更改应用配置后，将对应的服务重启。合肥的应用服务器检查HADG1和HADG2，根据读写属性，与数据库路由配置表比较，如果与当前配置不同，则更新路由配置表，更改应用配置后，将对应的服务重启。

（4）发卡系统准备两个探测交易供信用卡前置调用，一个为上海探测交易，一个为合肥探测交易，每个交易返回可写和可读的标志。信用卡前置根据交易可读写标志，切换交易。例如：如果上海的探测交易返回不可写，而合肥返回可写，则前置需要将交易都切换到合肥分中心，其他情况类似。

5 核心数据库迁移应用实践

信用卡核心系统数据库由IBM小机环境迁往X86环境，由于迁移前后为异构环境，不能采用原地升级方式，同时需要迁移的数据量为15T，停机的迁移窗口只有3h，所以不能采用传统的导入和导出方式。本次升级通过读取归档日志，增量方式将源数据日志，以逻辑方式应用到目标数据库中。

根据迁移方案，需要搭建与源环境一致的IBM小机环境中间环境数据库，源环境与中间环境为同构的数据库。目标数据库为X86环境，与源环境为异构数据库，使用逻辑方式OGG进行同步。

（1）通过DG进行主备同步，备机通过备份恢复初始化，主备通过网络同步应用日志。

（2）初始化19数据库期间，中间库接收日志，停止日志应用。

（3）通过DB LINK，将中间环境数据初始化到目标19C环境。

（4）启用源环境与中间环境的ADG的应用日志同步。

（5）通过OGG，将中间库同步到最终的目标数据库中。

整个信用卡核心数据库迁移期间，最后切换，数据比对在2h内完成，基本做到数据库和应用的平滑切换。

信用卡核心系统通过全闪存储部署，两地两中心部署，上海与合肥同时提供服务，交易处理能力大幅提高，提升到7倍以上，达到28000TPS。批量处理时间由5h缩短到2h之内。

浦发银行信用卡核心自2020年10月投产后，日均交易1.5亿笔，顺利通过“双十一”的业务峰值考验，数据库和应用性能表现平稳。