對於銀行的技術架構來說，賬戶體系是核心中的核心。在以往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年，業務架構上接觸過存款、貸款、客戶資訊等領域，進行過手機銀行、櫃面渠道等渠道應用研發，技術架構上了解過技術框架、分散式技術、網路安全、反欺詐風控、大資料等方向，擅長資料建模、架構建模並化繁為簡，喜歡看電子書，有一套快速閱讀方法。

——————