随笔：核心银行系统 之五 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小时业务，须要考虑柜员及网点轧账交易的支持，业务需考虑传票装订与柜员轧账的模式。

数据库表设计上，除分户帐外，新增一张影子分户表。

系统作完日终批量处理后，状为日间运行状态，此时全部的交易实时修改分户账的余额。在日切状态下的全部交易，不修改分户账的余额，其发生额写入影子分户。保持分户账余额不变，用于总分平衡检查等日终取上日余额。在追帐状态下的全部交易，实时修改分户账余额。日终处理的追账交易，根据影子分户里账户的发生额进行分户账余额的修改。在全部分户追账完成以后，系统状态改成日间运行状态。