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小时业务，需要考虑柜员及网点轧帐交易的支持，业务需考虑传票装订与柜员轧帐的模式。
数据库表设计上，除分户账外，新增一张影子分户表。
系统做完日终批量处理后，状为日间运行状态，此时所有的交易实时修改分户帐的余额。在日切状态下的所有交易，不修改分户帐的余额，其发生额写入影子分户。保持分户帐余额不变，用于总分平衡检查等日终取上日余额。在追账状态下的所有交易，实时修改分户帐余额。日终处理的追帐交易，根据影子分户里帐户的发生额进行分户帐余额的修改。在所有分户追帐完成之后，系统状态改为日间运行状态。
