3. 幂等性入门
在银行账务系统中，幂等性不是一个可选的“加分项”，而是资金安全与数据一致性的底线要求。一次转账请求因网络抖动被重复提交、一次扣款指令因超时重试被多次执行，都可能造成客户资金重复扣减或重复入账。理解幂等性，是构建可靠账务系统的第一道门槛。
一、幂等性的定义：从数学到工程
幂等性（Idempotence）最早来自数学。若函数 f 满足 f(f(x)) = f(x)，即对同一输入反复施加该函数，结果不再改变，则称该函数具有幂等性。例如绝对值函数 abs(abs(x)) = abs(x)，取最大值函数 max(x, c) 在重复执行后结果稳定。
在工程语境中，幂等性被扩展为：同一业务操作请求，无论被提交一次还是多次，对系统状态产生的最终影响相同。注意这里强调的是“最终影响相同”，而不是“每次返回完全一样”。例如重复提交一笔转账，系统可以第二次返回“已处理，请勿重复提交”，但账户余额不能再次变化。
核心公式化表达：设系统状态为 S，操作请求为 R，执行函数为 apply。若 apply(S, R) 执行 n 次后得到的状态与执行 1 次相同，即 applyn(S, R) = apply(S, R)，则该操作对 R 是幂等的。
二、幂等性在银行账务中的重要性
银行账务系统面临三类天然的不确定性：网络不可靠、客户端可能重试、消息中间件可能重复投递。没有幂等保护，这些不确定性会直接转化为资金差错。
- 资金安全：重复扣款、重复入账会直接损害客户利益，引发投诉、赔付与监管处罚。
- 对账一致性：账务流水、渠道流水、清算流水必须逐笔匹配，重复记账会破坏对账平衡。
- 系统可恢复性：超时重试、故障转移、消息重投是分布式系统的常规手段，幂等性是这些手段可用的前提。
- 监管合规：账务记录必须真实、准确、完整，重复记账属于严重的数据质量问题。
关键认知：幂等性解决的是“同一请求被多次送达”的问题，而不是“同一用户发起多笔不同请求”的问题。前者是技术重复，后者是业务意图，二者必须区分。
三、典型场景：重复记账从哪里来
重复记账并非罕见异常，而是分布式账务系统中的常态风险。以下场景在真实银行系统中反复出现：
| 场景 | 触发原因 | 重复风险 | 幂等防护要点 |
|---|---|---|---|
| 客户端超时重试 | 请求已到达但响应丢失 | 同一笔转账被扣款两次 | 业务请求号唯一约束 |
| 网关重试 | 上游调用超时后自动重发 | 同一扣款指令重复执行 | 网关层透传唯一请求ID |
| 消息队列重复投递 | 消费者确认失败，消息重投 | 同一入账消息被消费多次 | 消费端幂等表 + 去重键 |
| 定时任务重复触发 | 调度器故障转移或时钟漂移 | 同一批文件被重复处理 | 批次号 + 状态机控制 |
| 人工重复操作 | 柜员误点或系统无响应后重试 | 同一笔业务被录入两次 | 前端防重 + 后端唯一校验 |
这些场景的共同点是：请求本身可能携带相同的业务语义，但系统无法仅凭“收到一次请求”来判断是否已经处理过。因此，幂等设计必须引入一个可持久化的唯一标识，将“是否已处理”的判断从内存转移到数据库或分布式存储中。
四、幂等实现的基本思路与常见误区
实现幂等性的核心思路可以概括为“先查后写”或“唯一约束兜底”。常见做法包括：
- 唯一请求号：每笔业务生成全局唯一 requestId，处理前先查询是否已存在。
- 幂等表：建立独立幂等记录表，以 requestId 为主键，插入成功才允许继续处理。
- 状态机：业务单据设置“待处理、处理中、已成功、已失败”等状态，只有特定状态才允许推进。
- 数据库唯一索引：在账务流水表上对业务唯一键建立唯一索引，重复插入直接失败。
-- 幂等表典型结构
CREATE TABLE idempotent_record (
request_id VARCHAR(64) PRIMARY KEY,
biz_type VARCHAR(32) NOT NULL,
status TINYINT NOT NULL, -- 0处理中 1成功 2失败
created_at DATETIME NOT NULL,
updated_at DATETIME NOT NULL
);
-- 处理前尝试插入，插入成功才继续
INSERT INTO idempotent_record(request_id, biz_type, status, created_at, updated_at)
VALUES ('TRX202405200001', 'TRANSFER', 0, NOW(), NOW());常见误区一：认为“接口返回成功”就等于幂等。实际上，如果第一次处理成功但响应丢失，第二次请求仍可能再次执行扣款。
常见误区二：只在应用层用内存缓存去重。服务重启、多实例部署后缓存失效，重复请求仍会穿透。
常见误区三：把幂等键设置为“用户ID+金额+时间”，粒度太粗或太细都会导致误判：太粗会拦截正常业务，太细则无法覆盖重复请求。
五、幂等性与银行账务的边界
需要明确的是，幂等性并不等于“所有操作都可以随便重试”。对于查询类操作，天然幂等；对于更新类操作，需要显式设计；对于“追加”类操作，如记账流水，必须通过唯一键约束来保证不重复追加。银行账务中的幂等设计，最终要落到业务唯一键 + 持久化去重 + 状态机控制这三件套上。