隨筆：核心銀行系統 之五 7 X 24小時 不間斷運行的核心繫統設計

7 X 24小時 不間斷運行的核心繫統設計

普通大衆都以爲如今的互聯網系統都是全天候待機服務的，歷來不休息。其實，在銀行的核心繫統上作一筆交易，動軋更新幾百張表都是有可能的，那麼每筆交易都去這麼更新，以現行的計算機處理能力來講，要面對海量的客戶同時交易也是很不現實的。

那麼，如何作到核心系統一直在線，保證交易不中斷，又能知足交易須要更新這麼多表和處理的需求呢？

答案是，「聯機交易＋批量任務」 組合方式，來解決這個難題。其實，不止是核心系統，只要是有相似需求的系統，都會考慮用這種組合方式提供服務支持。

 

主要設計思想是，好比核心的聯機交易只負責記錄和更新當筆交易狀態和交易的帳戶餘額，對於如會計計提存款／貸款利息、計提費用、報表等每日或月末進行的處理採用日終批量任務來完成。

 

其餘系統，也可將非必要實時的處理用批量任務進行。

 

例如：

如下是典型的銀行系統日終批量由三步組成:日切(Cut Off)、日終批量(End Of Day)、 日初(Begin Of Day)。 

說明：日初批量(BOD)開啓一個銀行的邏輯處理日。如:按期存款到期處理、 常設指令執行。日切(Cutoff)標誌一個邏輯日的日切。將全部聯機交付渠道的交易日誌合併爲一個,用於批處理。同時爲下一工做日建立新的日誌。 日終批量(EOD)標記一個邏輯日的結束。處理交易日當天完成的交易。利息處理,當日在線交易過賬。這裏 EOD 包括了月末(EOM)、季末(EOQ)、 年底(EOY),如在月末那一天的 EOD 就是 EOM。 

 

具體實現方式：

例如：

雙餘額方式：

爲了能使聯機業務可以 24 小時不間斷,就要求聯機業務與批處理可以同時並行進行,爲此採用雙日期、雙餘額的分戶賬設計。

雙日期分別設爲‘最後交易日’和‘上次交易日’;雙餘額分別設置爲 ‘賬戶餘額’和‘上次賬戶餘額’及與餘額有關的‘餘額方向’和‘上次餘額方向’。 

系統的交易日期在系統中具備惟一性,它保存在系統的日期表中。

前臺顯示的日期來源於主機系統 的日期表(即交易後由後臺返回的日期)。若是後臺主機日期表的日期發生變動,聯機交易的日期也同時改變。 

換往後進行聯機記賬交易時,首先要檢查賬戶的‘最後交易日’與‘當前交易日’是否相同,若是 不一樣,說明該賬戶第一次更變餘額,此時要將‘賬戶餘額’放入‘上日餘額’,‘餘額方向’放入‘上 日餘額方向’,同時,‘最後交易日’更改成此‘當前交易日’。 

換往後進行批處理時,若是要進行總分覈對等與分戶餘額有關的處理時,首先要檢查‘最後交易日’ 與‘當前交易日’是否相同,若是相同,說明換往後進行此批處理過程前,此分戶已經發生過記賬 交易,它的‘賬戶餘額’已經發生了變化,這時就要用‘上日餘額’進行覈對或統計。 

 

 

單表雙餘額與雙表方式：

核心系統在夜間進行業務批量處理的時候，如計提結息需求，報表需求等，這些業務批量處理須要按帳戶當日日終餘額（或其餘數據）進行計算，故須要保持這些數據的必定靜止狀態，而夜間聯機交易須要更新帳戶餘額，在沒有7×24實現機制前，銀行都須要在批量運行時間段中止夜間的聯機交易，而在批量基本運行結束後再次開始聯機交易的對外服務。通常批量處理與聯機處理的衝突區就在帳戶餘額，解決批量用帳戶日終餘額與聯機用帳戶實時餘額的存儲與使用問題，便可很大程度上實現7×24業務服務。

 

實現7x24服務，最關鍵的要點在於保證兩份數據的準確並存：

• 動態實時數據（實時餘額）：主要是動帳及日間查詢交易使用
• 日切點的靜態數據（上日餘額）：主要用於批處理：好比計提、結息、總分覈對、向外圍（尤爲是財管、管會）供數等。

目前各廠商主要使用的方案有如下幾種：

• 單表雙餘額
• 雙表（雙表又分兩種：臨時表爲分戶臨時表或是流水臨時表）

 

1. 雙餘額動帳更新：

分戶帳上設置餘額、上日餘額、最後交易日期。根據以上字段來實現當前餘額、上日餘額的讀取和更新。

僅在動帳交易發生時纔可能更新上日餘額，即若是該帳戶長期無動帳，在此期間將不用更新上日餘額（其實此時的「上日餘額」字段從名稱上來看與實際是不符的）

1.1動帳處理：當日第一筆交易更新上日餘額、最後交易日期。

 

1.2獲取上日餘額處理

 

2. 雙餘額每日更新

分戶帳上設置餘額、上日餘額、最後交易日期。根據以上字段來實現當前餘額、上日餘額的讀取和更新。與「雙餘額動帳更新」方案不一樣的是，系統天天都會更新上日餘額及最後交易日期。（其實此時的「最後交易日期」字段從名稱來看與實際不必定相符。）

2.1日終批量刷新上日餘額

取上日餘額的場景都在日終，所以在日終切往後一開始就直接批量刷新上日餘額，便於後續讀取及供數。爲避免長時間鎖表，該批量任務逐筆處理。

對於一筆分戶帳，

IF 最後交易日期 < 會計日期

UPDATE 分戶帳  SET  上日餘額=當前餘額，最後交易日期=會計日期

2.2動帳處理：切往後，日終批量刷新須要一段時間，爲確保在此期間的聯機交易正常對外服務，動帳時仍採用如下處理。當日第一筆交易更新上日餘額、最後交易日期。

 

聯機交易與日終批量更新上日餘額有極小的可能會出現衝突（同時更新同一帳戶）。若是發生,解決以下：

若是批量鎖表，聯機失敗，交易重作將成功。

若是聯機鎖表，批量失敗，批量從新從斷點重跑。

2.3獲取上日餘額處理

取上日餘額的情景都在日終刷新以後，所以此時取上日餘額直接取分戶帳中的上日餘額。

 

3. 雙表

系統狀態

公共系統控制參數中的系統狀態分爲：

N：日間運行狀態(normal)

C：日切運行狀態(cutoff)

A：追賬運行狀態(append)

S：系統關閉(shutdown)

系統的C，A，N狀態是系統日終處理時進行的狀態切換。

 

系統關閉

核心業務系統處於關閉時，禁止因此業務運行。此狀態在出現特殊狀況時。

系統日間運行狀態

系統作完日終批量處理後，狀態未日間運行狀態，此時全部的交易實時修改分戶賬的餘額。

系統日切狀態

系統日終操做在作完當天的自動轉存等賬務處理後，在系統入總賬前，將系統的狀態改成日切狀態。在該狀態下的全部交易，不修改分戶賬的餘額，其發生額寫入影子分戶。保持分戶賬餘額不變，是爲了機構入總賬時進行總分平衡的檢查。

系統追賬狀態

系統日終入機構總賬結束後，系統狀態改成追賬。在這個狀態下的全部交易，實時修改分戶賬餘額。日終處理的追賬交易，對影子分戶裏賬戶的發生額進行分戶賬餘額的修改。在全部分戶追賬完成以後，系統狀態改成日間運行狀態。

• 系統只要不是運行在日終批處理狀態(CUTOFF狀態),也就是系統運行在正常狀態（NORMAL狀態）或追賬狀態（APPEND狀態），賬務處理API可修改分戶賬餘額；
• 系統只要是運行在日終批處理狀態(CUTOFF狀態)，記賬API就不能直接更改分戶賬餘額，而只能更改影子賬戶餘額。注意：在日終批處理狀態下,任何聯機交易均可能發生，因此開戶程序在寫分戶餘額時，只能將餘額記爲0,而真正的餘額必須記入影子賬戶中;一樣，銷戶時，不能將分戶餘額記爲0，而必須將發生額（也就是餘額）記入影子賬戶中。衝正交易的處理相同.
• 系統只要不是運行在N狀態（正常狀態），計算賬戶可用餘額時，必須將影子賬戶中的餘額和分戶賬中的餘額一塊兒合併計算。
• 因爲日切後，系統進入下一個賬務週期，因此賬務處理流水（如：分戶賬明細，分錄流水，子交易流水）中均記錄了賬務日期，於是不會和前一賬務日期相混淆。在備份這些庫表時，只要根據賬務日期處理便可。
• 任何賬戶，包括客戶賬，內部賬，處理方法是同樣的。
• 由後臺主機按照交易來肯定哪些交易容許在日終期間能夠開通。
• 若是櫃檯開通24小時業務，須要考慮櫃員及網點軋賬交易的支持，業務需考慮傳票裝訂與櫃員軋賬的模式。

數據庫表設計上，除分戶帳外，新增一張影子分戶表。

系統作完日終批量處理後，狀爲日間運行狀態，此時全部的交易實時修改分戶賬的餘額。在日切狀態下的全部交易，不修改分戶賬的餘額，其發生額寫入影子分戶。保持分戶賬餘額不變，用於總分平衡檢查等日終取上日餘額。在追帳狀態下的全部交易，實時修改分戶賬餘額。日終處理的追賬交易，根據影子分戶裏賬戶的發生額進行分戶賬餘額的修改。在全部分戶追賬完成以後，系統狀態改成日間運行狀態。