對於銀行的技術架構來説，賬户體系是核心中的核心。在以往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年，業務架構上接觸過存款、貸款、客户信息等領域，進行過手機銀行、櫃面渠道等渠道應用研發，技術架構上了解過技術框架、分佈式技術、網絡安全、反欺詐風控、大數據等方向，擅長數據建模、架構建模並化繁為簡，喜歡看電子書，有一套快速閲讀方法。
——————
版權聲明：本文源自 網絡， 於，由 楠木軒 整理發佈，共 4880 字。
轉載請註明： 高頻交易總延遲？2張表告訴你如何進行熱點設計！ - 楠木軒
