重复扣款，压垮骆驼的最后一根稻草
凌晨3:07，运维的电话把我炸醒：“支付接口疯狂重复回调，用户余额都成负数了！” 冲到电脑前看日志，一条订单被回调了11次——我们的系统没有幂等。这场景，做过金融支付的都懂。说实话，幂等性设计不是什么新概念，但真正落地的坑，踩一次脱一层皮。下文是我复盘三个通宵换来的教训，没有八股，只有干货。
数学定义与物理定律：到底什么是幂等？
先咬文嚼字——幂等，Idempotent，源自数学：一个函数f，满足f(f(x))=f(x)。什么意思呢？绝对值运算就是幂等的，abs(abs(-5))还是5；而翻倍运算不是，double(double(5))变成20。映射到计算机，意味着同一个操作执行一次和执行多次，最终结果和副作用必须一致。但分布式系统里问题复杂化了，因为“操作”可能跨多个服务。我们通常用唯一约束、状态机、令牌机制来实现。类比一下：自动门按钮，你连按十次和按一次，门只开一次，并且最终状态还是开——这就是幂等。而电梯按钮就不同了，按一次去5楼，再按取消不了，这可能引发重复请求。
我最欣赏的一种设计是基于令牌的乐观锁。客户端先申请一个全局唯一的令牌（Token），携带它执行业务操作，服务端校验令牌是否已使用。如果用了，直接返回上次的结果。这个机制简洁得像物理定律，没有复杂的分布式事务，却保证了最终一致性。但它也有陷阱，后面说。
压测数据不会说谎：2000 TPS与15%错误率的搏斗
为了验证幂等方案，我们对一个下单接口进行了压测。测试环境：8核16G，Spring Boot，Redis token校验，MySQL唯一索引兜底。JMeter线程数500，持续5分钟。
没加幂等时，TPS冲到2100，但错误率高达15.3%——全是DuplicateKeyException，数据库唯一索引都挡不住，因为并发竞争导致检查-插入间隙漏过去。加了幂等后，TPS降到1850，降了约12%，但错误率骤降至0.02%，仅仅是极少数网络超时触发重试被正确拦截。这个代价完全可接受，因为业务正确性远比吞吐量重要。而且经过优化，TPS降幅能缩到5%以内，比如把Token校验从Redis改为本地缓存+布隆过滤器。别迷信Redis，它的网络开销有时挺坑的。我们后来在网关层做了一层内存级的幂等，直接拦截80%的重复请求，后端压力骤降。
另一个教训：错误的幂等键设计会让TPS雪崩。有次同事用“用户ID+时间戳”做幂等键，结果毫秒级并发下，时间戳相同，导致不同请求被视为重复，订单丢失。改用业务订单号后解决。所以，键的选择必须保证业务唯一性。
三个陷阱，我掉进去两次
陷阱一：响应一致性的坑。 初次请求返回200，第二次同样的请求，系统幂等返回“重复请求”错误码，导致客户端解析异常。客户端重试机制往往期望得到相同的响应体。我们踩了：前端页面直接报错“操作过于频繁”。解决：缓存第一次的成功响应，下次幂等判定后返回相同的body和状态码。用Redis存储，key为幂等键，value为序列化的响应，过期时间=幂等有效期。
陷阱二：并发窗口期竞态。 令牌检查（SELECT）和插入（INSERT）不是原子的。即使用了唯一索引，高并发下仍可能抛出异常，业务就回滚了。血的教训是，数据库唯一索引必须作为兜底，但前端需要捕获异常并转为成功。更优雅的是用分布式锁，比如Redisson，在检查前加锁，但会引入性能瓶颈。折中方案：使用Redis的SETNX原子命令，通过Lua脚本实现“检查-设置”一步完成。我们的Lua脚本如下：if redis.call('SETNX', KEYS[1], ARGV[1]) == 1 then return 1 else return 0 end。简单，极致。
陷阱三：幂等键的过期时间。 设短了，已完成的订单重试被误拦；设长了，Redis内存爆炸。我们曾设置7天，结果大促时内存飙升，因为Token量太大。后来改成状态过期+主动删除：业务终态（如已支付）直接删Token，中间态保留短时间（30分钟）。需要配合数据库状态防止重复提交。工程美学，就藏在这些细节里。
以上，就是我拿三个通宵换来的清醒。幂等不难，难在边界条件的处理。你的系统真的幂等了吗？去压测一下，答案可能在凌晨三点的报错里。
