数据库事务可以保证一组操作的原子性和一致性，但它并不能防止重复的请求被多次执行。假如用户付款时网络卡顿，前端点击了两次提交按钮，后端收到了两条内容完全相同的支付请求，事务只会忠实地执行两次扣款——而这显然不是你想要的。这就引出了幂等性的概念。
幂等性的定义
在计算机领域，幂等性指的是对同一个操作执行一次或多次，产生的效果完全相同，且不会因为多次执行而产生副作用。用数据库的语言来说：同一条业务请求无论被处理多少次，最终数据库的状态应该与只处理一次一致。
幂等不是数据库自身的内建能力，而是你必须要在业务层面设计和实现的机制。事务只是工具，幂等才是策略。
为什么业务层必须考虑幂等
在真实的生产环境里，重复请求几乎不可避免，来源多种多样：
- 网络重试：客户端请求超时，框架自动重试，但第一次请求其实已经落库。
- 消息队列重复消费：消息中间件为保证可靠性，可能在消费者异常时重新投递已处理的消息。
- 用户重复操作：秒杀时快速刷新点击、表单多次提交。
- 服务间重试：微服务调用时为保证成功率，RPC 框架往往配置了失败重试。
如果接口不具备幂等性，轻则产生脏数据，重则引发资损（比如重复扣款、多发优惠券）。因此，凡涉及钱、订单、库存、积分、会员等级等关键状态变更的接口，都需要在设计之初就把幂等作为基本要求。
常见幂等性实现方案
实现幂等的思路多种多样，但所有方案本质上都是在“识别重复请求”和“跳过已处理请求”之间找一个平衡。以下是在 MySQL 体系下最常用且最可靠的几种做法。
1. 唯一索引/唯一约束
这是最经典的方案，通过数据库的“硬约束”天然保证幂等。你可以用请求中的唯一标识（比如订单号、流水号、外部交易单号）作为表的唯一索引，重复插入时直接触发 ER_DUP_ENTRY 错误，从而阻止重复的写入。
示例：创建支付流水表，将外部交易号设为唯一键。
CREATE TABLE payment_flow (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
out_trade_no VARCHAR(64) NOT NULL COMMENT '外部交易号',
amount DECIMAL(10,2) NOT NULL,
status TINYINT NOT NULL,
created_at DATETIME NOT NULL,
UNIQUE KEY uk_out_trade_no (out_trade_no)
);业务处理时，先做插入：
INSERT INTO payment_flow (out_trade_no, amount, status, created_at)
VALUES ('TRD20241201001', 100.00, 1, NOW());如果同样的 out_trade_no 再次插入，数据库会抛出 Duplicate entry 错误。此时应用可以捕获这个异常并判定为“重复请求”，然后查询该流水当前状态，直接向客户端返回原有结果，整个过程对用户透明。
这种方式的优点是实现简单、性能高、绝对可靠，因为唯一约束有数据库兜底。但它要求业务请求具备天然的唯一标识。如果没有这样的唯一标识，就需要先构造一个（例如按用户 ID + 操作类型 + 时间窗口生成）。
2. 状态机与乐观锁
当操作不是简单的“插入”，而是对已有记录的“更新”时，可以用有限状态机加上版本号或前置条件实现幂等。
比如一个订单的状态流转为：待支付 → 已支付 → 已完成。如果系统收到“已支付”的处理请求，但订单状态已经是“已支付”或“已完成”，就不能再次执行扣款或者发货，而应该直接返回成功。这时 UPDATE 语句可以携带状态条件：
UPDATE orders
SET status = '已支付', pay_time = NOW()
WHERE order_id = 1001 AND status = '待支付';如果这个更新影响了行数（affected rows）为 0，就表明状态已经被超前推进，不再是“待支付”。此时不应该再执行业务逻辑，而应视为重复调用。你可以在代码里判断 affected rows，若为 0 则直接返回已有状态。
为更加通用，可以用版本号字段：
UPDATE account
SET balance = balance - 50, version = version + 1
WHERE user_id = 1001 AND version = 5;如果版本号不匹配，说明数据已被其他操作更改，这次请求就不再执行。通过控制条件（CAS），避免了对同一余额的重复扣减。
这种方案的威力在于，它把幂等校验和业务逻辑合并到一个 SQL 中，效率极高，也避免了独立查询后再更新的竞态条件。
3. 去重表 + 本地事务
有些场景比较复杂：一次业务操作可能由多条 SQL 构成，无法用单条唯一索引覆盖，或者唯一键的粒度覆盖不到整个操作。此时可引入一个专门的“幂等去重表”。
设计一张和业务无关的通用表：
CREATE TABLE idempotent_record (
idempotent_key VARCHAR(128) PRIMARY KEY,
created_at DATETIME NOT NULL
);执行业务逻辑前，先向该表插入此次请求的唯一键（例如 服务名+业务标识+操作时间窗口内唯一 ID）。由于主键冲突会直接报错，如果插入失败，就代表这次请求已处理过，直接返回成功。插入成功后，再在同一个事务里执行核心业务逻辑。一旦业务逻辑中途失败、回滚，由于幂等记录也回滚了，下次重试就能正常执行。
这种方式通用性强，但会引入额外的写入开销，而且去重表可能会随时间增长变得很大，需要通过定时清理或分区来维护。
4. Token 令牌机制
这也是一种常见的去重手段，适用于表单提交流程。提交页时前端先向服务端申请一个唯一 Token，并携带在提交请求中。服务端拿到 Token 后，在同一个 Redis/表中检验 Token 是否已被使用（通常用 SETNX 或 DELETE + 插入记录）。检验通过后执行业务逻辑。
比如，利用 Redis 的 SET NX EX 原子操作：
SET token:abc123 1 NX EX 300如果返回 OK，表示 Token 未被使用；如果返回 nil，则重复请求。Redis 速度极快，适合高并发场景。如果业务要求强一致性，也可以用 MySQL 的唯一索引和事务来管理 Token。
选择方案的考量维度
面对具体的业务场景，选择幂等方案时需要权衡以下因素：
- 唯一标识的存在性：是否已有天然的全局唯一 ID（如订单号、流水号）？如果有，直接用唯一索引是最简洁的。
- 操作类型：是插入操作还是更新操作？插入用唯一约束，更新用状态机加条件或版本号。
- 性能要求：超高并发时，唯一索引轻量无锁，性能最优；去重表加额外写操作，有微量开销但仍可接受。
- 生命周期管理：去重表或 Token 需要定期清理，否则存储膨胀，必须配套清理策略。
- 失败处理策略：重复请求到底返回成功还是报错？通常业务上希望返回“成功”的幂等效果，让客户端无感。这就需要代码捕获重复异常并做降级处理。
幂等与事务的结合
幂等性设计必须跑在事务的框架里，否则毫无意义。因为如果幂等检查和业务操作不在同一个事务内，就可能出现查了没重复但业务执行后却没来得及写入幂等标识的情况，导致下次无法识别。
因此，所有幂等方案都强调原子性：
- 唯一索引本身就是原子操作，无需额外关心。
- 去重表的插入必须与业务 SQL 在同一个本地事务中。
- Token 使用如果是数据库管理，也需要与业务操作共同提交或回滚。
总结与开发铁律
在实际开发中，有几条简单好用且经过大量验证的铁律可以遵循：
- 只要有外部单号，就建唯一索引：这是代价最小、最可靠的幂等实现。
- 状态更新必须带前置条件：永远不要写
UPDATE ... SET status='已支付' WHERE id=1001，一定要加上AND status='待支付'。 - 幂等记录与业务数据放进同一个事务：不依赖外部缓存去幂等地修改数据库，除非你能接受不一致。
- 返回结果要幂等：重复请求不但不能改变数据，还要返回相同或兼容的业务结果，让调用方认为一切正常。
业务层的幂等设计，就是用少量的代码冗余换取数据绝对的洁净。它不是一个技术炫技的环节，而是你在面对资金、库存、权益类数据时，必须习惯带上的安全带。写惯了“无幂等”的业务逻辑，一旦切换到高并发、高可靠性系统里，吃亏的往往是数据和用户信任。