信用卡核心系統性能提升研究與實踐

上海浦東發展銀行信息科技部開發中心 林 朋

隨著信用卡業務發展，信用卡業務已經突破了傳統的服務邊界，變得無處不在，各種業務混合場景融合，這對于信用卡核心系統的性能要求越來越高。

浦發銀行信用卡核心系統數據庫集中部署在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億筆，順利通過“雙十一”的業務峰值考驗，數據庫和應用性能表現平穩。