从一次线上故障场景开始
先看关键判断
如果你正在处理CDN API，先别急着照搬网上的参数。想象一下：你是一个电商网站的后台运维人员，某天突然接到大量用户投诉，说同一笔订单被重复扣款了。你惊慌失措地检查支付接口日志，发现源站API确实收到了两次完全相同的请求——订单号、金额、时间戳一模一样。更诡异的是，你并没有写循环，用户也只点了一次“提交”。这到底是怎么回事？
罪魁祸首很可能就藏在你的CDN边缘节点里。CDN（内容分发网络）通常被用来加速静态资源，但很多团队也会把API接口（尤其是POST请求）放在CDN后面，期望获得更快的响应速度。然而，CDN边缘节点为了“保证服务质量”，会内置一套自动重试机制：当它向后端源站发送请求后，如果在规定时间内没有收到正常响应（比如源站负载过高导致超时，或者网络丢包），节点就会自动重发一次请求。这个机制的本意是好的，就像快递员没敲开门会再试一次。但如果你的API接口不具备“幂等性”，问题就来了——两次完全相同的请求会导致源站执行两次写操作，比如生成两个订单、扣除两次余额。
概念拆解：什么是CDN边缘节点的重试机制？与CDN API
验证与回滚
CDN（Content Delivery Network）本质上是一个由全球各地边缘服务器组成的分布式网络。当用户请求某个资源（比如一张图片或一个API接口）时，CDN会通过DNS调度，让用户连接最近的边缘节点。如果该节点没有缓存，它会代表用户向源站发起请求，获取结果后再返回给用户，同时缓存一份。
问题是，网络通信并非100%可靠。边缘节点与源站之间的TCP连接可能因网络抖动而中断，源站处理请求的时间可能超过预设的超时阈值，或者源站返回的HTTP状态码是5xx（服务器错误）……在这些情况下，CDN边缘节点会触发重试机制。不同CDN服务商的重试策略不同：有的会立即重试一次，有的会间隔几秒再试，有的甚至允许配置重试次数（比如最多3次）。但核心逻辑相同：只要没得到明确的成功响应，节点就认为请求失败，然后重新发送完全相同的请求。
关联教程：此处可内链到“CDN API部署与验证”内容。
核心概念：幂等性与非幂等性与CDN API
先看关键判断
“幂等性”（Idempotent）是一个数学概念，在编程中表示：无论执行多少次相同的操作，结果都和执行一次一样。例如，GET请求通常是幂等的——即使你刷新10次页面，服务器也不会因为你重复请求而创建10条新记录。PUT请求也常被设计为幂等的：比如“将用户的昵称改为‘张三’”，执行一次和一百次的效果相同。
但POST请求却不是天然幂等的。POST通常用于创建资源（比如创建订单、提交表单），每次执行都会在服务器上产生一个新结果。这就是“非幂等性API接口”。用一个生活化类比：
– 幂等接口：你按电梯按钮，按一下电梯会来，按十下它还是只来一次。
– 非幂等接口：你按门铃，按一下门会响一声，按两下就响两声。第二次按不是多余的，而是产生了新的效果。
当CDN重试机制遇上非幂等接口，问题就浮出水面了：重试会直接导致服务器执行两次“按门铃”的动作。
进阶阅读：此处可内链到“CDN API性能优化”指南。
问题根源：重试时机窗口与状态不确定
容易忽略的细节
要彻底理解这个故障，需要深入重试发生的精确时间点。假设源站API处理一次下单请求需要500毫秒，但CDN边缘节点配置的超时时间是300毫秒。于是会出现以下时间线：
- 第0毫秒：用户请求到达边缘节点，节点向源站转发请求。
- 第300毫秒：源站还在处理中（比如正在写入数据库），但节点已经等了300毫秒没收到任何响应，判定超时。
- 第300～350毫秒：节点立刻或稍作延迟后，重新发送一次完全一样的请求。
- 第500毫秒：源站完成第一次请求的处理（订单创建成功）。
- 第505毫秒：源站收到第二次请求，再次执行同样的逻辑（创建第二个订单）。
结果是两个订单都被写入数据库，但用户只看见一个请求。哪怕源站后续返回了响应给节点，节点也可能忽略第一次响应的内容，直接将第二次响应的结果返回给用户。但在用户看来，他看到的只是第二次请求的结果（成功的提示），而不知道后台已经执行了两次。
还有一些更隐蔽的情况：比如源站在第一次响应前发生了网络丢包，节点完全没收到响应，那重试是合理的。但如果第一次响应已经成功发出，只是在传输中延迟了，节点重试会导致“重复执行”。更糟糕的是，有些CDN节点会在接收到超时响应（如504 Gateway Timeout）后立刻重试，而不管源站是否已经处理了请求。
想继续深入：此处可内链到“CDN API优化清单”文章。
真实世界的“灾难”案例
配置前的检查
这类故障并不是理论推演。2017年，某知名云服务商曾因CDN边缘节点重试机制导致用户订单重复；2020年，另一家大型票务平台在演唱会抢票高峰时，因为CDN重试和数据库锁机制冲突，造成了“超售”问题。实际上，只要你的API是写操作且非幂等，一旦前置CDN开启了重试，就相当于在源头制造了重复流量。
你可能会问：“那我关闭CDN的重试功能不就行了？” 问题是，很多CDN服务商默认开启重试，且不允许用户完全关闭（因为这是保证可用性的重要手段）。即使允许关闭，你也会面临一个两难选择：关闭重试 = 网络抖动时用户会直接收到50x错误；开启重试 = 写操作可能重复。这就需要更精细的设计来应对。
延伸阅读：此处可内链到“CDN API配置案例”相关文章。
解决思路：在应用程序层面实现幂等性
容易忽略的细节
最彻底的解决方案，是把自己的API接口改造成幂等的。具体怎么做？利用幂等令牌（Idempotency Key）机制。
客户端在发起非幂等请求时，生成一个全局唯一的键（比如UUID），放在HTTP请求头中发送给服务器。服务器在处理请求前，先检查这个键是否已经被处理过。如果已经处理，直接返回之前的结果（比如订单ID），不再重复执行；如果没有处理，则正常执行并记录该键。
这样即使CDN重试了请求，两次请求携带的幂等键是相同的，服务器只会执行一次写操作。幂等键的存储可以用Redis（设置TTL过期），也可以用数据库。这种方案被Stripe、PayPal等支付网关广泛采用。
对于无法快速改造接口的团队，还有以下折中方案：
- 在CDN层面限制重试范围：只允许幂等的请求类型（如GET、HEAD、DELETE等）重试，而对POST/PATCH/PUT配置不重试。但这需要CDN支持按HTTP方法区分策略，且无法覆盖所有场景。
- 在边缘节点增加请求去重：比如基于请求体Hash值，在短时间内对完全相同的请求进行去重（类似缓存）。缺点是会增加边缘节点的内存开销，且无法处理因响应超时导致的并发重复。
- 在源站使用乐观锁或业务去重：例如在订单表中对“订单号+用户ID”设置唯一索引，第二次插入会直接失败。但这种方法要求业务字段本身具有唯一性。
相关阅读：此处可内链到“CDN API常见问题”专题。
验证与回滚建议
实际操作要点
如果你怀疑当前CDN配置正在导致重复请求，可以这样验证：
- 在源站API日志中查找“相同请求体+相同请求时间戳（误差在几秒内）”的重复记录。
- 模拟网络延迟环境：在源站前增加一个代理，人为引入1000ms的延迟，然后观察CDN是否会发出重复请求。
- 查看CDN访问日志：关注HTTP状态码为499（客户端关闭连接）或504的请求，以及紧随其后的相同请求。
一旦确认问题，最安全的回滚操作是：
- 临时关闭该API路径的CDN加速，直接回源。
- 或者在CDN控制台关闭该路径的“重试”功能（如果支持）。
- 之后尽快在上述方案中选择一种实施改造。
总结：理解重试，拥抱幂等
配置前的检查
CDN边缘节点重试机制本身是一种“负责任的”容错设计，但它在非幂等接口面前却成了灾难源头。理解了这两个核心概念后，你就拥有了排查此类问题的理论武器。对于小白运维来说，记住一条黄金法则：所有经过CDN或负载均衡器的非幂等写操作，都必须实现幂等性保障。无论是通过幂等键、唯一索引还是业务去重，只有把接口设计的“百毒不侵”，才能放心享受CDN加速带来的红利。把这些步骤跑通后，CDN API基本就能稳定落地。
延伸阅读