本文共2268字 | 建議閱讀時間：5分鐘

作者：張廣

在核心系統的設計實現中，24小時機制向來是一個重點難點。早期的銀行只有柜面一個業務辦理渠道，因此當時的綜合業務系統，跟隨網點的營業時間，分為日起，營業，日結，日終批量這幾個階段。所有網點日結后，才開始日終批量，這時是不辦理聯機業務的。

隨著科技發展，銀行逐漸開展了自助設備，網上銀行，手機銀行等多種電子渠道，接入了支付系統，銀聯系統等第三方接口。這時，對核心系統就提出了的24小時支持的要求。

24小時實現機制有準24小時和真24小時之分。

準24小時是核心系統在日切時停止聯機交易一小段時間，待日切完成后再啟動聯機，通常時間控制在幾分鐘內，這段時間內未完成的聯機交易被強行中斷，不接收新的交易請求。真24小時是不停聯機，在任意時間聯機交易都可以正常發送處理，不會中斷。

下面總結的就是真24小時的實現方案。要做到真24小時，需從以下幾個方面解決。

1、 分戶賬的改造

分戶賬處理主要有兩種情況。

一是交易的記賬日期可以先發生次日，再發生前日。例如，日切后先發生過次日的聯機交易，再執行日終批處理記上日賬。又比如，在日切點交易并發時，日切后的交易先被調度到執行完畢，日切前的交易后被調度執行。

二是日終批處理中能獲取上日結束的準確余額。

主要的解決方法有AB表法，追賬法，雙字段法等幾種，其中最優的當屬雙字段法。在分戶賬表中設置當前余額，上次更新日期，上日余額。發生交易時，用交易日期與上次更新日期比較。如果交易日期大，說明進入新的一天，將當前余額搬入上日余額，再更新當前余額，記錄上次更新日期為交易日期。如果相等，說明是當天的后續交易，只更新當前余額，上日余額和上次更新日期不變。如果交易日期小，說明先發生了次日交易，這時同時更新上日余額和當前余額，上次更新日期不變。在日終批處理獲取上日余額進行統計時，同樣先判斷上次更新日期，如果上次更新日期小于或等于上日，說明新的一天沒發生過交易，取當前余額，否則說明新的一天已發生交易，取上日余額。2、?序號表的改造

核心系統有很多序號，是按周期設置的，最常見的是日序號，每天從1重新開始。原先常見的做法是，通過日切后一個序號初始化批處理，批量清零。

24小時情況下就不能如此了，同樣也要考慮兩個日期以及先后順序的問題。與分戶賬類似，使用雙字段法給序號表設置當前序號，上次更新日期，上日序號，解決不同日期交易取用的問題。

3、?明細類的改造

明細類包含有賬戶明細，記賬傳票流水等這類帶日期的記錄表。

以往的系統，在日切過程中進行當前表刪除并導入歷史表的操作，導出期間會影響按日期的查詢結果，這也是24小時需要避免出現的。

解決方法是，將這類表按日期分表或分區，操作時根據日期就可算出應該操作的表名或分區名，免除了數據的搬移。這樣在任意時間均可支持正確的寫入和查詢。

4、?沖正交易的改造

外圍發起沖正時，無法判斷何時日切，因此核心應只提供統一的沖正交易，后臺根據原交易記賬日期和當前日期判斷是當日沖正還是隔日沖正，并支持隔日沖正的處理。

特別提一點，批處理中，日切這一任務應等待1個聯機交易超時時間，以防批處理過快，前日的交易未處理完就在后續批處理任務中獲取上日余額。

此外，系統在版本更新時，也需要考慮如何盡量支持不停止聯機服務。更新時還需注意一定要保證同一筆交易內不同程序版本的一致性，不能出現部分舊版本部分新版本的情況。

5、?程序版本更新時的處理

如果應用系統支持運行中動態加載卸載庫和名稱綁定，例如Unix環境的動態鏈接庫，則可以通過控制交易結束后開始前進行動態庫的卸載加載，來保證交易內程序版本的一致性。

這種方式對于普通修復是可以了，但有時會嚴格要求新舊版本不能并存，切換時間點后必須全部執行新版本，這時候就要用額外的方法了，即暫掛請求交易的處理。

在每個并發進程上一交易結束后，接收完新的連接請求，下一交易開始前，通過標志控制暫停處理，可以保持連接。當所有并發進程都處于暫停狀態時，說明原有交易均已處理完成。

版本更新后，修改標志放開處理，這時原先暫掛的交易會繼續處理，對外感覺僅僅是這筆交易響應時間變長了，并未發生服務的中斷。

6、?參數表內容更新時的處理

通常參數表是加載至緩存的，因此只要控制緩存更新的時機即可。參數表不會太大，緩存更新很快能完成，因此放在交易結束后開始前加載更新。

同樣，如果嚴格要求新舊不能并存，也仍需要暫掛請求交易處理。

7、?數據庫表結構更新時的處理

表結構的變動分為新增表，刪除表，新增字段，修改刪除字段這幾類。新增表和刪除表時通過操作順序很容易做到不停止聯機服務。

新增表時先建表，后更新程序，刪除表時先更新程序，后刪表。新增字段，修改刪除字段可以通過SQL語句進行，執行期間會鎖表，因此需要預先評估SQL執行時間長短。

如果表數據量較大則需要用以下的方式實現切換：首先暫掛交易的接收請求處理，將原表rename為舊表，并以新的結構建立空的新表。修改訪問這個表的所有程序，改為訪問新表和舊表的合集的版本。

隨后開放交易處理，并以后臺進程的方式，逐漸將舊表的記錄一點一點搬移至新表，直到舊表為空。最后修改訪問這個表的所有程序，恢復成僅訪問新表的版本即可。

隨著銀行對服務可用性要求越來越高，核心系統的設計也應當充分考慮，盡可能實現完全不停機的連續運行，這也是設計人員對優秀核心系統的追求目標。

----------? END? ----------

也許你還想看

銀行核心系統項目過程步驟銀行核心系統在銀行IT架構中的功能邊界銀行核心系統之分表分區和批處理性能優化