🗄️ 数据库与接口总览
3核心维度
5+报文标准
10+测试要点
8+性能场景
数据库与接口是银行核心系统的"骨架"与"血管"。核心库表承载全行账户、交易、账务数据；接口体系串联各系统间的资金流与信息流。本章系统梳理银行核心数据库设计原则、分库分表策略、接口体系架构及主流报文标准。
📐 知识维度概览
🗃️ 核心库表设计
账户主表、交易流水表、账务明细表、参数配置表等核心表结构设计原则，字段命名规范与索引策略
🔀 分库分表策略
基于账号Hash/范围/模数的水平拆分、冷热数据分离、读写分离、分库分表中间件选型与路由策略
🗃️ 银行核心库表设计原则
1. 数据模型分层
银行核心系统数据模型通常分为三层：
| 层级 | 说明 | 典型表举例 |
|---|---|---|
| 基础数据层 | 相对静态的参考数据与参数配置 | 机构表、柜员表、利率参数表、产品定义表、币种表、节假日表 |
| 合约/协议层 | 客户与银行之间的契约关系 | 客户信息表、账户主表、存款合约表、贷款合同表、担保合同表 |
| 交易/事件层 | 高频变动的交易流水与账务明细 | 交易流水表、账务明细表、会计分录表、冲正记录表 |
2. 核心表设计原则
- 账户主表（ACCT_MAIN）：以账号为主键，包含账户类型、币种、余额、利率、开户日期、账户状态等核心字段。余额字段需支持多币种精度，状态字段需包含正常、冻结、止付、销户等枚举值
- 交易流水表（TRANS_LOG）：以流水号为主键，含交易日期、交易时间、交易码、借贷标识、交易金额、对方账号、摘要等。支持按日期分表，索引覆盖流水号+交易日期+账号的组合查询
- 账务明细表（ACCT_DETAIL）：记录每笔影响账户余额的明细，含交易后余额、发生额、起息日等。与交易流水一一对应，用于账务回溯与对账
- 参数配置表（PARAM_CONFIG）：以参数编码+生效日期为联合主键，含参数值、参数类型、状态等。参数变更需保留历史版本，支持按日期区间回溯
- 会计分录表（JOURNAL_ENTRY）：遵循复式记账，每笔交易至少产生一借一贷两条分录。含科目号、币种、金额、借贷方向、摘要等
3. 关键设计约束
设计红线交易流水表和账务明细表必须做到不可篡改，采用只追加（Append-Only）模式，任何冲正/抹账操作都通过新增反向记录实现，绝不允许物理删除或修改原记录。
- 金额字段精度：采用DECIMAL(18,2)或DECIMAL(18,4)（外汇场景），严禁使用浮点数类型
- 时间戳精度：交易时间精确到毫秒级，用于并发场景下的交易排序与幂等判断
- 乐观锁机制：账户余额更新采用版本号（VERSION）乐观锁，防止并发扣款导致余额不一致
- 审计追踪：关键表（账户、交易、参数）需含创建人、创建时间、更新人、更新时间字段
🔀 分库分表策略
1. 水平拆分
| 拆分策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 按账号Hash取模 | 账户主表、交易流水表 | 数据分布均匀，路由简单 | 扩容需数据迁移，Hash碰撞处理 |
| 按日期范围 | 交易流水表、账务明细表 | 便于历史数据归档，扩容无需迁移 | 热点集中在近期分区 |
| 按机构/分行 | 机构独立核算场景 | 天然隔离，便于管理 | 数据倾斜风险（大分行 vs 小分行） |
| 冷热分离 | 交易流水、日志表 | 降低热库压力，节省存储成本 | 跨冷热查询需额外路由 |
2. 分库分表中间件选型
| 中间件 | 模式 | 核心能力 | 适用场景 |
|---|---|---|---|
| ShardingSphere | JDBC代理/Sidecar | 分库分表、读写分离、分布式事务 | Java技术栈银行系统 |
| MyCAT | 数据库代理 | 分库分表、读写分离、SQL兼容 | 遗留系统兼容改造 |
| Vitess | 云原生代理 | 自动分片、连接池、故障转移 | 分布式/云化核心系统 |
测试要点分库分表后需重点验证：跨分片查询的正确性与性能、分布式事务的一致性、扩容/缩容的数据重分布、分片键选择对热点数据的影响。
🔗 接口体系架构
1. 银行系统间接口层次
| 接口层 | 协议 | 典型场景 | 报文格式 |
|---|---|---|---|
| 渠道接入层 | HTTP/HTTPS、Socket | 网银、手机银行、柜面 → 核心 | JSON、XML、定长报文 |
| 核心交易层 | TCP/IP Socket、MQ | 核心 ↔ 支付系统、信贷系统、卡系统 | ISO8583、定长报文、Tuxedo FML |
| 支付清算层 | MQ、文件传输 | 核心 ↔ 人行CNAPS、超级网银、银联 | ISO8583、XML、CIPS报文 |
| 国际结算层 | SWIFTNet、MQ | 核心 ↔ SWIFT Alliance、代理行 | SWIFT MT/MX |
| 监管报送层 | 文件传输、ETL | 核心 → 反洗钱、EAST、1104、征信 | 定长文本、XML、CSV |
2. 接口适配模式
- 协议转换网关：统一接入层接收JSON请求，内部转换为ISO8583/Tuxedo报文调用核心，返回时再转回JSON
- 报文映射引擎：通过配置化的映射规则（字段名、编码转换、枚举映射）实现不同报文格式间的双向转换
- ESB企业服务总线：作为系统间通信中枢，提供路由、协议转换、报文校验、流量控制等能力
- 消息队列削峰：高并发交易场景（如双十一、年终结算）通过MQ缓冲，保护核心系统不被流量冲垮
测试关注接口测试需重点关注：协议转换的正确性（报文字段映射无遗漏/无错位）、超时重试的幂等性、异常返回码的覆盖率、消息队列的积压与消费能力边界。
🧪 功能测试要点
数据库设计验证
- 字段精度验证：验证金额字段 DECIMAL 精度是否满足业务要求（含分位舍入），利率字段小数位数是否满足定价精度（通常6-8位）
- 约束完整性：主键、唯一键、外键约束是否正确；NOT NULL 字段是否有默认值；CHECK 约束是否覆盖业务规则（如状态枚举值）
- 索引有效性：通过 EXPLAIN 验证核心查询语句的索引命中情况，避免全表扫描；复合索引的列顺序是否匹配查询模式
- Append-Only审计：验证交易流水表和账务明细表无 UPDATE/DELETE 权限，所有修改通过插入反向记录实现
- 乐观锁并发：模拟并发扣款场景，验证版本号机制防止余额覆盖更新，冲突时返回明确错误码
分库分表验证
- 路由正确性：验证分片键路由算法的一致性，同一账号的所有操作落入同一分片
- 跨分片查询：验证跨分片 JOIN/聚合查询结果的正确性，特别是涉及排序、分页、去重
- 分布式事务：验证跨分片转账的一致性（A分片扣款 + B分片入账），模拟中间异常回滚
- 扩容数据迁移：验证在线扩容时数据重分布的完整性，迁移期间读写一致性
接口协议验证
- 报文格式校验：验证请求/响应报文的结构符合协议规范，字段必填/选填、长度、类型、编码
- 字段映射准确性：验证协议转换网关的字段映射表，逐一核对源字段与目标字段的对应关系和编码转换
- 异常返回码：覆盖所有错误码分支（超时、账户不存在、余额不足、参数非法等），验证返回码和错误描述的正确性
- 加解密验证：验证敏感字段（密码、PIN、CVV）的加密传输与存储，MAC校验和签名验证
⚡ 性能测试要点
数据库性能
- 场景：千万级账户表上的核心交易查询（按账号查余额、按流水号查交易、按日期范围查明细）
- 目标：单表查询 P99 ≤ 10ms（走索引），跨分片聚合查询 P99 ≤ 100ms
- 验证点：索引覆盖率、SQL 执行计划、Buffer Pool 命中率、磁盘 IOPS
- 压测方案：模拟生产数据量级（亿级流水），混合读写场景（70%读+30%写），梯度加压至峰值 TPS 的 2 倍
并发扣款压力
- 场景：高并发场景下同一账户的并发扣款（例如双十一支付、工资日批量代发）
- 目标：乐观锁冲突率 ≤ 5%，成功交易 P99 ≤ 50ms，无死锁
- 验证点：行锁等待时间、死锁检测与自动解除、连接池耗尽恢复
- 压测方案：50线程并发操作同一账户，混合扣款+查询+充值，持续30分钟
接口吞吐量
- 场景：综合交易接口（账号查询、动账交易、密码校验）的全链路压力
- 目标：单接口 TPS ≥ 5000（核心交易），P99 ≤ 200ms（含协议转换）
- 验证点：ESB/网关吞吐瓶颈、报文序列化/反序列化耗时、连接池配置、Socket 缓冲区
- 压测方案：模拟 2000 并发长连接，区分短交易（查询）和长交易（转账），混合比例 8:2
消息队列削峰
- 场景：瞬时流量洪峰（如秒杀、年终结算），消息队列积压百万级消息
- 目标：消息零丢失，消费延迟 P99 ≤ 5秒，无消息积压雪崩
- 验证点：MQ Broker 吞吐上限、消费者并发度、消息重试与死信队列、消费幂等性
- 压测方案：生产者以 10倍峰值速率投递，观察消费者lag增长与恢复时间