對于銀行的技術架構來說，賬戶體系是核心中的核心。在以往IOE的架構中，銀行核心系統每秒可支持萬級金融交易，對熱點賬戶的支持仍需一定技巧。在基礎技術設備自主研發的當下，如何進行國産化的熱點賬戶設計成為各家銀行的關注重點，本文作者通過對熱點賬戶的技術實現進行深入解剖，詳述了提升吞吐量的“時空”方案，并以冒煙測試和餘額不足測試兩個思維實驗進行了進一步佐證。

作者 | 區偉洪 責編 | 楊陽

出品 | 《新程序員》編輯部

自2019年我國正式提出發展信創産業，信創相關政策也如雨後春筍般相繼出台。在相關政策的影響下，各行各業紛紛出台信創相關政策，力求在新一輪發展潮流中搶得先機。金融信創成為信創落地應用進展最快的領域，其中，核心系統國産化是銀行業信創的重要陣地，各家銀行目前在如火如荼地攻陷這塊陣地。

賬戶體系是銀行核心系統的“中樞神經”，在IBM大型機技術的支持下，全國性大銀行的賬戶體系每秒可支持高達萬級的金融交易，中小銀行的賬戶每秒亦可支持成百上千的金融交易。但既然要大力推進銀行核心系統國産化，就需要放棄IBM的大型機技術，轉向使用基于國産化數據庫的設計，這對賬戶體系的設計形成不小的挑戰。要繼續支持每秒萬級金融交易，就必須讓設計更有技巧。

挑戰：支持熱點賬戶的高頻交易

最大的挑戰來自于熱點賬戶，它是賬戶體系中一種能支持高頻交易的賬戶。熱點賬戶在業務處理上的要求與普通賬戶幾乎沒有差别，但在交易頻率上的要求比普通賬戶高，普通賬戶的交易一般為幾天一次乃至幾周、幾個月一次，而熱點賬戶的出賬、入賬頻率可能達到每秒幾百次，甚至上千次。

在電子商城中，商戶的交易賬戶是一種典型的熱點賬戶，目前民衆的消費大多是通過線上進行的，一個熱門商戶的賬戶可能有每秒數千個出入賬記錄，分攤到每家銀行，至少要求單個銀行的賬戶能支持每秒500個出入賬交易。若銀行的支持能力低于這個要求，商戶就會向更有能力的銀行尋求支持，部分金融交易就會分流到其他銀行，甚至可能改投其他銀行懷抱。

為什麼支持熱點賬戶的高頻交易有一定難度？可以從金融交易的處理流程說起。如圖1所示，金融交易的業務步驟一般為：常規檢查、餘額檢查、餘額變更、後置處理。其中，餘額檢查、餘額變更、後置處理是對賬戶數據有變更操作的，計算機在技術處理上，為了保證交易的原子性、完整性、一緻性，防止賬務差錯，就要加入事務控制。在一般的技術設計中，都是在餘額檢查前開啟事務，在後置處理後提交事務。

圖1 普通扣賬過程示意圖

事實上，一個賬戶在同一時間隻能被一個用戶開啟事務，事務開始後該用戶方能對該賬戶進行變更操作。其餘用戶如需操作該賬戶，就要等待該用戶結束事務後，競争得到開啟事務權利的其中一個用戶才能操作。未競争到開啟事務權利的用戶就要進入新一輪等待。當多個用戶并發同時向同一個賬戶進行轉賬時，就形同千軍萬馬過獨木橋，同一時間隻能有一個用戶過橋，其餘用戶需要排隊等候。圖2演示了這種等候情況。

圖2 并發用戶等待情況示意圖

假如轉賬操作的平均耗時為n毫秒，用戶1、用戶2、用戶3在0毫秒時同時要轉賬給同一賬戶，由于有事務控制，用戶1在0毫秒時拿到賬戶操作權利，在n毫秒時轉賬結束，實際處理時間為n毫秒；用戶2在0毫秒時要等待用戶1事務結束，在n毫秒時拿到賬戶操作權利，在2n毫秒時轉賬結束，實際處理時間為2n毫秒；用戶3在0毫秒時要等待用戶1事務結束，在第n毫秒時要等待用戶2事務結束，終于在第2n毫秒時拿到賬戶操作權利，在第3n毫秒時轉賬結束，實際處理時間為3n毫秒。

由于事務控制，單個熱點賬戶要達到每秒支持500個交易請求，按上面的推導過程，就是要500n小于或等于1000毫秒（一秒等于1000毫秒），需要一次轉賬操作的時間小于2毫秒。這在普通的交易流程設計下，使用IBM大型機技術作為支持可能勉強達到。而國産化數據庫是運行在普通計算機上的軟件，支持普通設計下的一次轉賬通常要耗時幾十到200毫秒。這就要采用有技巧的技術設計，保證既能遵守業務要求，又能支持熱點賬戶的高頻交易。

思路：提升吞吐量的“時空”方案

提升計算機系統吞吐量（并發量）的辦法，歸根結底有兩個：一是增加“獨木橋”的數量或增加“橋”的寬度，讓同一時間可以有更多的用戶“過橋”；二是減少用戶“過橋”的時間，單位時間内能讓更多的用戶“過橋”。前者是空間方案，後者是時間方案，兩者雙管齊下效果更佳。

本文的設計在空間方案上盡量将賬戶的事務控制去掉，讓多個用戶可以同時執行轉賬過程的不同階段操作，增加了“橋”的數量；在時間方案上，将原來部分聯機執行的交易步驟改為由計算機系統後台自動延時執行，這樣用戶聯機執行的步驟少了，縮短了“過橋”時間。

分析

在轉賬的四個步驟中，常規檢查、餘額檢查兩個步驟是必須聯機執行的。執行常規檢查确定交易符合監管合規要求，進行基本的風險控制。同時必須執行餘額檢查确保賬戶有足夠餘額進行轉賬，避免銀行賠錢。

餘額變更則可以改為延時執行，有計算機後台将多筆轉賬金額求和，一次變更賬戶餘額，避免了對該賬戶開啟事務的次數過多。普通方案下，對一個熱點賬戶500次轉賬需要開啟500次事務，延時處理設計下，隻需開啟1次事務。

後置處理是記錄操作日志、交易流水、會計核算記賬等操作，這些操作本來就對用戶無感，隻是銀行為了記錄交易痕迹，事後核對賬務正确性而設計的記錄性操作，也可以和餘額變更一同改為延時執行。

概述

經過以上分析，熱點賬戶的處理過程可設計為如圖3所示。

圖3：熱點賬戶聯機、延時扣賬過程處理示意圖

在該設計中，聯機步驟的事務控制基本去掉了，當然是指整個過程的長時間事務被去掉。長時間事務的去除相當于增加了“獨木橋”的數量或增加了“橋”的寬度，而一些短暫的數據庫操作仍存在占用時間很短的事務，但這種小事務不影響“橋”的寬度。

表設計

在銀行核心系統原有的表設計基礎上增加了《餘額占用表》和《延時任務表》，用以輔助去掉長時間事務，以及輔助聯機步驟傳遞交易信息給延時步驟。《餘額占用表》的關鍵字段設計如表1所示。

表1 《餘額占用表》的關鍵字段設計

《延時任務表》的關鍵字段設計如表2所示。

表2 《延時任務表》的關鍵字段設計

以上兩個表在結構上幾乎一樣，記錄的數據幾乎也一樣，但不應合并為同一個表。因為《延時任務表》起着降低操作執行時間，減小事務時間長度的作用。

聯機步驟

有了上述的知識準備，下面說說整個交易的詳細處理過程，首先從聯機處理步驟說起。

第一步，常規檢查：用戶提交轉賬請求，計算機系統首先執行常規檢查，确定交易符合監管合規要求，進行基本的風險控制。如不符合要求則返回錯誤提示給用戶。

第二步，餘額檢查-1：先開啟短事務然後往《餘額占用表》插入一筆記錄，含流水号、賬号、交易金額、會計日期、記錄創建時間，并馬上結束這次短事務，确保剛插入的數據庫記錄對其他用戶可見。（關鍵點：事務馬上提交。）

第三步，餘額檢查-2：對《餘額占用表》的同賬号的、創建時間小于等于本交易創建時間的記錄的交易金額求和，如果是正數，則無須檢查賬戶餘額，因為不會造成短款（即銀行要補錢）；如果是負數，表示要從當前賬戶餘額減去的金額，需要對比賬戶餘額，夠扣則繼續執行後續步驟，不夠扣則删除《餘額占用表》本交易的記錄并返回餘額不足給用戶。（關鍵點：查詢條件創建時間小于等于本交易創建時間，另若删除《餘額占用表》本交易的記錄失敗需在延遲步驟中徹底處理。其實不删讓延時任務處理也可以，這樣更快。）

第四步，生成任務：第三步檢查通過表示交易的條件已就緒，其餘處理放在延時步驟中即可。那麼，往《延時任務表》插入一筆延時任務，含流水号、賬号、交易金額、會計日期、《餘額占用表》的記錄創建時間、狀态0等，插入成功則返回交易成功給用戶。這次插入操作也是個短事務。（關鍵點：插入《延時任務表》一筆記錄，比更新《餘額占用表》中本交易的記錄耗時要短得多。）

聯機步驟至此結束，步驟不多，且事務時間很短，所以幾乎沒有瓶頸。

延時步驟

聯機步驟執行成功，交易就可以認為成功了，隻是交易資金臨時放在延時任務表中，沒有入賬。延時步驟主要處理資金入賬及相關後置操作。延時處理步驟是個定時任務，例如1分鐘執行一次。下面具體介紹延時步驟每次被觸發後的處理過程。

第一步，加載任務：加載《延時任務表》中待處理的賬号并去重，針對每個賬号，執行以下步驟。

第二步，餘額變更：從未處理的賬号中選擇一個賬号進行處理，根據該賬号加載《延時任務表》中待處理的任務，區分不同的會計日期，彙總金額更新到賬戶餘額中，處理日終餘額。

第三步，後置處理：根據《延時任務表》交易入賬時間升序排列，逐行處理排好序的結果集，記錄賬戶的交易流水，進行會計核算記賬，記錄金融交易操作日志，更新任務狀态為已處理。

第四步，循環處理：重複以上第二步、第三步，直至第一步選出的賬号處理完畢，然後結束本次處理，等待下一次被觸發處理。

實驗：冒煙測試&餘額不足測試

本文以思維實驗的形式，舉例對上述方案進行驗證，同時，借助所舉的思維實驗例子加深大家對方案的理解。

冒煙測試（思維實驗）

先介紹一個簡單的實驗，賬号為“ACCOUNT1”，初始餘額為1000，在一秒内收到4筆扣賬交易請求。

經過聯機步驟處理後，《餘額占用表》和《延時任務表》的記錄如下（見表3、表4）。由于流水号為TRX001的處理時間稍長，此時尚未來得及登記入《延時任務表》。

表3 《餘額占用表》

表4 《延時任務表》

定時任務觸發了一次延時處理，流水号為TRX002、TRX003、TRX004的交易被延時處理，ACCOUNT1的餘額被一次性更新為920。《餘額占用表》和《延時任務表》的記錄如表5、表6所示。

表5 《餘額占用表》

表6 《延時任務表》

TRX001的聯機步驟在定時任務執行完後處理完成，《餘額占用表》和《延時任務表》的記錄如表7、表8所示。

表7 《餘額占用表》

表8 《延時任務表》

在下一次延時處理前沒有交易進入，此次延時處理則按第2點的方式進行了批量處理，但僅處理了TRX001這筆交易。數據庫記錄的情況顯而易見，不再展示。

餘額不足測試（思維實驗）

賬号ACCOUNT1，初始餘額為1000，在一秒内收到4筆扣賬交易請求，扣賬金額分别為300、400、500、600。

第一筆交易TRX001進來，扣賬300，執行聯機步驟完成後，數據情況如表9、表10所示。

表9 《餘額占用表》

表10 《延時任務表》

第二、第三筆交易同時進來，分别扣賬400、500，執行聯機步驟途中，數據情況如表11、表12所示。

表11 《餘額占用表》

表12 《延時任務表》

由于餘額檢查中TRX001、TRX002、TRX003的扣賬金額之和為1200，大于ACCOUNT1的賬戶餘額，TRX002、TRX003的餘額占用記錄被删除，并返回餘額不足錯誤給用戶。由于第2點的TRX002、TRX003餘額占用記錄被删，此時數據情況與第1點相同。

第四筆交易進來，扣賬600，此時沒有并發的交易進來，餘額檢查通過，交易成功，《餘額占用表》和《延時任務表》各增加了TRX004的記錄，數據不再展示。

其他

請大家參照上述兩個思維實驗腦補其他情況以驗證該設計的完備性。

結語

截至本文完稿時間，本設計已在某銀行國産化核心系統實施，并進行了SIT環境壓力測試，基本可達成設計目标，相信在生産環境更優的硬件支持下，該方案會有更 佳的表現。

本文僅讨論了熱點賬戶設計的關鍵邏輯的設計。不同的銀行有不同的銀行核心系統賬戶體系設計，還需要結合不同的賬戶體系設計實現沖正、日切、計息等處理。此外，還需加入技術架構上的單元化、分庫分表、分布式事務等與技術棧相關的設計，方能形成完善的可落地的熱點賬戶個性化設計，歡迎就此與筆者讨論。

作者介紹

區偉洪，某銀行資深工程師，從業近20年，業務架構上接觸過存款、貸款、客戶信息等領域，進行過手機銀行、櫃面渠道等渠道應用研發，技術架構上了解過技術框架、分布式技術、網絡安全、反欺詐風控、大數據等方向，擅長數據建模、架構建模并化繁為簡，喜歡看電子書，有一套快速閱讀方法。

而在金融專題中，來自中國工商銀行、郵政儲蓄、中信銀行、廣發銀行、中國人民銀行、平安科技、微衆銀行、螞蟻集團等十數家傳統金融機構和頭部金融科技公司的技術專家為我們帶來了關于各類新一代颠覆性技術的深入讨論和案例分析。深入解答開發者應該如何更好融入金融産業，以及金融科技的人才培養之道，真正做好金融科技的技術創新和數字化轉型。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部