系统架构设计师 · 高频练习

客户端超时重试支付请求时,幂等键应该怎样使用?

高级 单选题 第 937 题 中等 系统架构设计师Idempotency Key支付重试请求去重分布式系统
题目

客户端提交支付请求后未收到响应,于是用相同业务参数重试。为避免服务端重复扣款,较合理的幂等设计是()。

A 每次重试都生成新的幂等键,让服务端把它们当成不同支付
B 完全依赖客户端按钮置灰,服务端不做重复请求判断
C 所有用户永久共用同一个幂等键
D 同一次逻辑支付复用同一幂等键,服务端保存处理状态和结果,并校验请求指纹
题目类型:原创高频练习题 用途:用于帮助理解系统架构设计师相关考点和答案解析,不等同于官方真题。
正确答案
D
答案解析

幂等键应标识一次逻辑操作,而不是一次网络尝试。服务端在合适作用域内记录幂等键、请求摘要和处理结果;相同请求重试可返回原结果,不同参数复用同一键应拒绝或告警。

选项分析

A

错误。重试换新键会绕过去重逻辑,服务端可能把每次尝试都当成新支付。

B

错误。按钮置灰只能改善界面操作,处理不了网络重试、并发请求或恶意调用。

C

错误。全局共用一个键会让彼此无关的业务互相冲突,也无法表达操作边界。

D

正确。键、作用域、请求指纹、状态和原结果共同构成可靠幂等处理。

本题为什么容易错

最常见误区是把幂等键当成“每个 HTTP 请求的流水号”。它应该跟随一次业务意图,而不是跟随每次网络发送。

先看结论

简短答案

客户端超时重试支付请求时,幂等键应该怎样使用,正确答案是 D(同一次逻辑支付复用同一幂等键,服务端保存处理状态和结果,并校验请求指纹)。幂等键应标识一次逻辑操作,而不是一次网络尝试。服务端在合适作用域内记录幂等键、请求摘要和处理结果;相同请求重试可返回原结果,不同参数复用同一键应拒绝或告警。

解析

易混淆概念对比表

概念本题判断区别要点记忆提示
每次重试都生成新的幂等键,让服务端把它们当成不同支付 本题干扰项 错误。重试换新键会绕过去重逻辑,服务端可能把每次尝试都当成新支付。 看到该词不要急着选,先判断是否真正解决题干问题
完全依赖客户端按钮置灰,服务端不做重复请求判断 本题干扰项 错误。按钮置灰只能改善界面操作,处理不了网络重试、并发请求或恶意调用。 看到该词不要急着选,先判断是否真正解决题干问题
所有用户永久共用同一个幂等键 本题干扰项 错误。全局共用一个键会让彼此无关的业务互相冲突,也无法表达操作边界。 看到该词不要急着选,先判断是否真正解决题干问题
同一次逻辑支付复用同一幂等键,服务端保存处理状态和结果,并校验请求指纹 本题正确答案 正确。键、作用域、请求指纹、状态和原结果共同构成可靠幂等处理。 看到题干核心场景时优先联想到它
本题易混淆选项怎么区分
  • 每次重试都生成新的幂等键,让服务端把它们当成不同支付:错误。重试换新键会绕过去重逻辑,服务端可能把每次尝试都当成新支付。
  • 完全依赖客户端按钮置灰,服务端不做重复请求判断:错误。按钮置灰只能改善界面操作,处理不了网络重试、并发请求或恶意调用。
  • 所有用户永久共用同一个幂等键:错误。全局共用一个键会让彼此无关的业务互相冲突,也无法表达操作边界。
复习

知识点详解

可靠幂等接口通常让调用方生成高熵键,并在用户、商户或接口作用域内唯一。服务端需以原子方式创建处理记录,保存请求指纹、状态和响应。重复请求若参数一致,可返回原结果或当前状态;参数不一致则不能当作同一操作。幂等记录还需考虑保留期限、并发竞争、下游副作用和人工补偿,单靠缓存一个键并不足以覆盖完整支付链路。

备考速记

一次业务一把键,重试不换键,换参数不能偷用旧键。

Idempotency Key 在分布式系统场景中的作用

Idempotency Key在本题中的核心价值,是解决“客户端提交支付请求后未收到响应,于是用相同业务参数重试。为避免服务端重复扣款,较合理的幂等设计是()”这个场景问题。复习时不要只背选项名称,还要理解它为什么适用于该场景,以及它能解决哪类安全、流程或管理问题。

拓展

同类题怎么考

  • 支付、创建订单、发券等接口超时重试。
  • 区分幂等、去重、Exactly-once 宣称与业务唯一约束。
Idempotency Key 在系统架构设计师软考中的考法

软考选择题通常不会只考概念定义,还会把Idempotency Key放到分布式系统场景中,要求判断它的作用、适用范围或与相近概念的区别。遇到这类题时,先抓住题干中的业务场景,再看哪个选项最能解决该场景下的核心问题。

解题思路

网络超时只说明客户端没收到结果,不代表服务端没扣款。正确做法是让一次支付从第一次提交到所有重试都带同一把钥匙。服务端第一次处理时占住这把钥匙并记录状态;后续相同请求不再重新扣款,而是等待或返回原结果。还要比对金额、订单号等请求指纹,防止同一键被拿来支付另一笔业务。

考点定位

幂等不是“请求只发送一次”,而是同一逻辑请求重复到达后,业务效果仍等价于执行一次。

易错提醒

  • 先执行扣款,成功后才写入幂等记录,留下并发窗口。
  • 只保存成功结果,不处理进行中、失败可重试和超时状态。
  • 同一键对应的请求参数发生变化时仍静默返回旧结果。

备考提示

  • 画出首次请求、响应丢失、重试到达三个时刻。
  • 继续思考幂等记录的作用域、过期策略、并发原子性和故障恢复。

你可能还想了解

  • 幂等键应该由客户端还是服务端生成?
  • 同一个幂等键参数不同怎么办?
  • 幂等记录应该保留多久?

本文小结

同一次逻辑支付的所有重试应复用同一幂等键。服务端原子记录请求指纹、状态和结果,相同重试返回原结果,参数变化则拒绝,避免重复扣款。