4. 核心银行关键业务场景
核心银行系统承载的是银行最本质的资金与账务能力。可靠性工程在这里不是抽象指标，而是每一笔存款、取款、转账、贷款、支付清算、日终批处理与联机交易都必须"账实相符、可追溯、可恢复"。理解这些业务场景的差异，是设计可靠性方案的前提：联机交易追求低延迟与强一致，批处理追求吞吐与可重跑，清算追求对账准确与差错可控。本章从业务特征出发，梳理各场景的可靠性要点与工程方法。
一、核心原理：账务一致性与交易生命周期
核心银行的可靠性根基是"借贷平衡"与"状态机可控"。任何一笔资金变动，本质上都是账户余额的原子更新加上一条不可篡改的流水记录。联机交易的生命周期通常为：请求接入 → 校验（账户状态、限额、密码）→ 记账（借方与贷方同时成功或同时失败）→ 登记流水 → 返回结果。其中"记账"必须在一个数据库事务内完成，否则会出现单边账。
日终批处理则是另一套逻辑：它把当日联机产生的流水汇总、计息、计提、生成总账，并完成与清算系统的对账。批处理允许"重跑"，但必须保证幂等——同一批数据重复执行不会造成重复扣款或重复计息。因此，可靠性设计的关键词是：事务、幂等、对账、补偿、可重入。
二、方法流程：分场景的可靠性设计
不同业务场景对可靠性的诉求差异明显，需要分别设计。下表梳理了七类场景的核心特征与可靠性抓手。
| 业务场景 | 一致性要求 | 典型风险 | 可靠性抓手 |
|---|---|---|---|
| 存款 | 强一致、实时入账 | 重复入账、现金与账不符 | 幂等流水号、冲正机制 |
| 取款 | 强一致、余额校验 | 超取、并发扣减 | 行级锁、余额乐观校验 |
| 转账 | 借贷原子、跨行最终一致 | 单边账、超时悬挂 | 本地事务+对账补偿 |
| 贷款 | 本金利息精确、状态机 | 计息错误、状态错乱 | 版本控制、计息重算 |
| 支付清算 | 对账一致、差错可追 | 长短款、清算延迟 | 日间对账、差错池 |
| 日终批处理 | 批量幂等、可重跑 | 漏跑、重复计提 | 批次号、断点续跑 |
| 联机交易 | 低延迟、高可用 | 超时、连接耗尽 | 限流、熔断、快速失败 |
以转账为例，跨行转账的可靠性流程可概括为：发起方扣款并登记"处理中"流水 → 调用清算通道 → 收到成功回执后置为"成功"，超时则进入"待对账"状态 → 日终与清算系统对账，差错进入差错池人工或自动处理。整个过程依赖状态机驱动，而非简单的成功/失败二元判断。
-- 转账流水状态机（简化）
CREATE TABLE transfer_flow (
flow_id VARCHAR(32) PRIMARY KEY, -- 幂等键
from_acct VARCHAR(24) NOT NULL,
to_acct VARCHAR(24) NOT NULL,
amount DECIMAL(18,2) NOT NULL,
status VARCHAR(16) NOT NULL, -- PROCESSING/SUCCESS/FAILED/PENDING_RECON
retry_count INT DEFAULT 0,
created_at TIMESTAMP,
updated_at TIMESTAMP
);
-- 幂等约束：同一 flow_id 只允许一次成功记账
CREATE UNIQUE INDEX uk_flow_success ON transfer_flow(flow_id, status);三、案例场景：日终批处理的重跑与对账
某银行日终批处理在计息环节因下游文件延迟而中断。运维人员直接重跑整个批次，结果部分账户被重复计息。复盘发现：计息任务没有按"账户+日期"做幂等控制，重跑时无法识别已处理数据。改进方案是引入批次号与断点标记：每个子任务记录已完成的账户区间，重跑时跳过已完成部分；同时计息结果先写入临时表，校验总额平衡后再切换生效。
这个案例说明，批处理的可靠性不靠"小心操作"，而靠"设计上允许重跑"。断点续跑、临时表切换、总额校验是三个可复用的模式。
四、误区与复盘
- 误区一：把联机交易的重试当成万能药。对于扣款类交易，盲目重试可能造成重复扣款。重试必须配合幂等键，且只对"确定未成功"的请求重试。
- 误区二：认为批处理失败只需重跑。若任务本身非幂等，重跑会放大错误。必须先确认幂等性，再决定重跑范围。
- 误区三：忽视对账的实时性。只做日终对账，差错会累积一整天。关键清算通道应增加日间准实时对账，缩短差错发现窗口。
- 误区四：联机与批处理共用同一套资源。日终批处理大量占用数据库和IO，可能拖垮夜间联机交易。应做资源隔离与错峰调度。
把上述场景放在一起看，核心银行的可靠性工程可以归纳为一条主线：用事务守住单笔交易的原子性，用幂等守住重跑与重试的安全性，用对账守住跨系统的一致性，用补偿守住最终收敛。联机与批处理虽节奏不同，但都服务于"账实相符"这一根本目标。掌握这条主线，才能在后续的容量规划、故障演练与应急恢复中做出正确取舍。