ASP.NET Core 生产实践试题 07：背压、限流与并发限制
121 关于速率限制，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 每秒允许一百个请求就保证同时最多只有一百个请求
- B. 它不直接限制单个慢请求占用资源的并发数量
- C. 只要观察到“慢请求导致并发量远超速率阈值”，就能把这次现象视为所有环境中的固定行为。
- D. 速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理
查看答案与解析
正确答案D
正确项给出了速率限制可直接依赖的规则：“速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理”。“它不直接限制单个慢请求占用资源的并发数量”是应用规则前必须确认的边界，不是规则本身；“每秒允许一百个请求就保证同时最多只有一百个请求”则把常见现象或实现细节扩大成了平台保证。场景“慢请求导致并发量远超速率阈值”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
122 生产环境出现“慢请求导致并发量远超速率阈值”时，针对速率限制应如何排查？
难度： 进阶
- A. 直接采用“每秒允许一百个请求就保证同时最多只有一百个请求”解释现象，不再收集目标进程和发布配置证据。
- B. 先验证“它不直接限制单个慢请求占用资源的并发数量”，再使用运行时指标、日志或最小复现检查“速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理”是否成立。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“它不直接限制单个慢请求占用资源的并发数量”的验证。
- D. 只检查代码是否能够编译，通过后便认定“速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理”在当前部署中必然成立。
查看答案与解析
正确答案B
“慢请求导致并发量远超速率阈值”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“它不直接限制单个慢请求占用资源的并发数量”，再以“速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理”组织证据。采用误区“每秒允许一百个请求就保证同时最多只有一百个请求”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
123 评审速率限制相关实现时，以下哪项判断不成立？
难度： 实战
- A. 每秒允许一百个请求就保证同时最多只有一百个请求
- B. 速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理
- C. 它不直接限制单个慢请求占用资源的并发数量
- D. 遇到“慢请求导致并发量远超速率阈值”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“每秒允许一百个请求就保证同时最多只有一百个请求”正是速率限制的典型误区。主规则“速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理”描述了实现应依赖的契约，边界“它不直接限制单个慢请求占用资源的并发数量”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
124 准备上线涉及速率限制的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“每秒允许一百个请求就保证同时最多只有一百个请求”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理”修改代码，但不核对“它不直接限制单个慢请求占用资源的并发数量”或目标发布模式。
- C. 依据“速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理”实现，在“它不直接限制单个慢请求占用资源的并发数量”成立的环境中验证，并为“慢请求导致并发量远超速率阈值”保留可观测证据和回退条件。
- D. 只验证“它不直接限制单个慢请求占用资源的并发数量”，实现仍继续依赖“每秒允许一百个请求就保证同时最多只有一百个请求”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“速率限制控制时间窗口内允许的请求数量或令牌消耗，适合配额和突发治理”，部署环境满足“它不直接限制单个慢请求占用资源的并发数量”，并能在“慢请求导致并发量远超速率阈值”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
125 关于并发限制，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 并发限制控制同时进入受保护区域的请求数量，并可配置有限排队
- B. 并发限制能够保证同一业务命令只执行一次
- C. 容量应按下游瓶颈而非只按 CPU 核数确定
- D. 只要观察到“数据库连接池被瞬时并发耗尽”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了并发限制可直接依赖的规则：“并发限制控制同时进入受保护区域的请求数量，并可配置有限排队”。“容量应按下游瓶颈而非只按 CPU 核数确定”是应用规则前必须确认的边界，不是规则本身；“并发限制能够保证同一业务命令只执行一次”则把常见现象或实现细节扩大成了平台保证。场景“数据库连接池被瞬时并发耗尽”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
126 生产环境出现“数据库连接池被瞬时并发耗尽”时，针对并发限制应如何排查？
难度： 进阶
- A. 直接采用“并发限制能够保证同一业务命令只执行一次”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“容量应按下游瓶颈而非只按 CPU 核数确定”的验证。
- C. 先验证“容量应按下游瓶颈而非只按 CPU 核数确定”，再使用运行时指标、日志或最小复现检查“并发限制控制同时进入受保护区域的请求数量，并可配置有限排队”是否成立。
- D. 只检查代码是否能够编译，通过后便认定“并发限制控制同时进入受保护区域的请求数量，并可配置有限排队”在当前部署中必然成立。
查看答案与解析
正确答案C
“数据库连接池被瞬时并发耗尽”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“容量应按下游瓶颈而非只按 CPU 核数确定”，再以“并发限制控制同时进入受保护区域的请求数量，并可配置有限排队”组织证据。采用误区“并发限制能够保证同一业务命令只执行一次”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
127 评审并发限制相关实现时，以下哪项判断不成立？
难度： 实战
- A. 并发限制控制同时进入受保护区域的请求数量，并可配置有限排队
- B. 容量应按下游瓶颈而非只按 CPU 核数确定
- C. 遇到“数据库连接池被瞬时并发耗尽”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
- D. 并发限制能够保证同一业务命令只执行一次
查看答案与解析
正确答案D
题目要求找出不成立的判断，“并发限制能够保证同一业务命令只执行一次”正是并发限制的典型误区。主规则“并发限制控制同时进入受保护区域的请求数量，并可配置有限排队”描述了实现应依赖的契约，边界“容量应按下游瓶颈而非只按 CPU 核数确定”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
128 准备上线涉及并发限制的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“并发限制能够保证同一业务命令只执行一次”完成修改，只要本地运行一次成功就立即发布。
- B. 依据“并发限制控制同时进入受保护区域的请求数量，并可配置有限排队”实现，在“容量应按下游瓶颈而非只按 CPU 核数确定”成立的环境中验证，并为“数据库连接池被瞬时并发耗尽”保留可观测证据和回退条件。
- C. 按照“并发限制控制同时进入受保护区域的请求数量，并可配置有限排队”修改代码，但不核对“容量应按下游瓶颈而非只按 CPU 核数确定”或目标发布模式。
- D. 只验证“容量应按下游瓶颈而非只按 CPU 核数确定”，实现仍继续依赖“并发限制能够保证同一业务命令只执行一次”这一未经证明的假设。
查看答案与解析
正确答案B
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“并发限制控制同时进入受保护区域的请求数量，并可配置有限排队”，部署环境满足“容量应按下游瓶颈而非只按 CPU 核数确定”，并能在“数据库连接池被瞬时并发耗尽”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
129 关于队列上限，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 增加无限队列可以在不丢请求的同时保持低延迟
- B. 有限排队能吸收小突发，队列满时应尽快返回明确过载响应
- C. 长队列会把过载转化为高尾延迟并占用客户端超时预算
- D. 只要观察到“请求排队时间超过客户端超时”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案B
正确项给出了队列上限可直接依赖的规则：“有限排队能吸收小突发，队列满时应尽快返回明确过载响应”。“长队列会把过载转化为高尾延迟并占用客户端超时预算”是应用规则前必须确认的边界，不是规则本身；“增加无限队列可以在不丢请求的同时保持低延迟”则把常见现象或实现细节扩大成了平台保证。场景“请求排队时间超过客户端超时”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
130 生产环境出现“请求排队时间超过客户端超时”时，针对队列上限应如何排查？
难度： 进阶
- A. 直接采用“增加无限队列可以在不丢请求的同时保持低延迟”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“长队列会把过载转化为高尾延迟并占用客户端超时预算”的验证。
- C. 只检查代码是否能够编译，通过后便认定“有限排队能吸收小突发，队列满时应尽快返回明确过载响应”在当前部署中必然成立。
- D. 先验证“长队列会把过载转化为高尾延迟并占用客户端超时预算”，再使用运行时指标、日志或最小复现检查“有限排队能吸收小突发，队列满时应尽快返回明确过载响应”是否成立。
查看答案与解析
正确答案D
“请求排队时间超过客户端超时”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“长队列会把过载转化为高尾延迟并占用客户端超时预算”，再以“有限排队能吸收小突发，队列满时应尽快返回明确过载响应”组织证据。采用误区“增加无限队列可以在不丢请求的同时保持低延迟”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
131 评审队列上限相关实现时，以下哪项判断不成立？
难度： 实战
- A. 增加无限队列可以在不丢请求的同时保持低延迟
- B. 有限排队能吸收小突发，队列满时应尽快返回明确过载响应
- C. 长队列会把过载转化为高尾延迟并占用客户端超时预算
- D. 遇到“请求排队时间超过客户端超时”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案A
题目要求找出不成立的判断，“增加无限队列可以在不丢请求的同时保持低延迟”正是队列上限的典型误区。主规则“有限排队能吸收小突发，队列满时应尽快返回明确过载响应”描述了实现应依赖的契约，边界“长队列会把过载转化为高尾延迟并占用客户端超时预算”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
132 准备上线涉及队列上限的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“增加无限队列可以在不丢请求的同时保持低延迟”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“有限排队能吸收小突发，队列满时应尽快返回明确过载响应”修改代码，但不核对“长队列会把过载转化为高尾延迟并占用客户端超时预算”或目标发布模式。
- C. 依据“有限排队能吸收小突发，队列满时应尽快返回明确过载响应”实现，在“长队列会把过载转化为高尾延迟并占用客户端超时预算”成立的环境中验证，并为“请求排队时间超过客户端超时”保留可观测证据和回退条件。
- D. 只验证“长队列会把过载转化为高尾延迟并占用客户端超时预算”，实现仍继续依赖“增加无限队列可以在不丢请求的同时保持低延迟”这一未经证明的假设。
查看答案与解析
正确答案C
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“有限排队能吸收小突发，队列满时应尽快返回明确过载响应”，部署环境满足“长队列会把过载转化为高尾延迟并占用客户端超时预算”，并能在“请求排队时间超过客户端超时”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
133 关于分区限流，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 直接使用任意客户端 Header 作为分区键天然安全
- B. 分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸
- C. PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略
- D. 只要观察到“攻击者不断变换伪造键绕过配额”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案C
正确项给出了分区限流可直接依赖的规则：“PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略”。“分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸”是应用规则前必须确认的边界，不是规则本身；“直接使用任意客户端 Header 作为分区键天然安全”则把常见现象或实现细节扩大成了平台保证。场景“攻击者不断变换伪造键绕过配额”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
134 生产环境出现“攻击者不断变换伪造键绕过配额”时，针对分区限流应如何排查？
难度： 进阶
- A. 直接采用“直接使用任意客户端 Header 作为分区键天然安全”解释现象，不再收集目标进程和发布配置证据。
- B. 只增加机器资源或重启进程，以一次恢复结果代替对“分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸”的验证。
- C. 只检查代码是否能够编译，通过后便认定“PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略”在当前部署中必然成立。
- D. 先验证“分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸”，再使用运行时指标、日志或最小复现检查“PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略”是否成立。
查看答案与解析
正确答案D
“攻击者不断变换伪造键绕过配额”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸”，再以“PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略”组织证据。采用误区“直接使用任意客户端 Header 作为分区键天然安全”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
135 评审分区限流相关实现时，以下哪项判断不成立？
难度： 实战
- A. PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略
- B. 直接使用任意客户端 Header 作为分区键天然安全
- C. 分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸
- D. 遇到“攻击者不断变换伪造键绕过配额”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案B
题目要求找出不成立的判断，“直接使用任意客户端 Header 作为分区键天然安全”正是分区限流的典型误区。主规则“PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略”描述了实现应依赖的契约，边界“分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
136 准备上线涉及分区限流的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略”实现，在“分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸”成立的环境中验证，并为“攻击者不断变换伪造键绕过配额”保留可观测证据和回退条件。
- B. 依据“直接使用任意客户端 Header 作为分区键天然安全”完成修改，只要本地运行一次成功就立即发布。
- C. 按照“PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略”修改代码，但不核对“分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸”或目标发布模式。
- D. 只验证“分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸”，实现仍继续依赖“直接使用任意客户端 Header 作为分区键天然安全”这一未经证明的假设。
查看答案与解析
正确答案A
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“PartitionedRateLimiter 可按用户、租户、API Key 等键应用独立策略”，部署环境满足“分区键必须来自可信且数量受控的身份，否则会造成绕过或状态爆炸”，并能在“攻击者不断变换伪造键绕过配额”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。
137 关于业务幂等，哪一项准确描述了应依赖的平台契约？
难度： 基础
- A. 限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理
- B. 配置 RateLimiter 后支付请求绝不会重复扣款
- C. 多实例下进程内锁和本地限流无法形成全局唯一执行保证
- D. 只要观察到“客户端超时重试产生重复命令”，就能把这次现象视为所有环境中的固定行为。
查看答案与解析
正确答案A
正确项给出了业务幂等可直接依赖的规则：“限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理”。“多实例下进程内锁和本地限流无法形成全局唯一执行保证”是应用规则前必须确认的边界，不是规则本身；“配置 RateLimiter 后支付请求绝不会重复扣款”则把常见现象或实现细节扩大成了平台保证。场景“客户端超时重试产生重复命令”只能作为排查线索，仍需结合目标框架、发布方式和运行时证据验证。
138 生产环境出现“客户端超时重试产生重复命令”时，针对业务幂等应如何排查？
难度： 进阶
- A. 直接采用“配置 RateLimiter 后支付请求绝不会重复扣款”解释现象，不再收集目标进程和发布配置证据。
- B. 先验证“多实例下进程内锁和本地限流无法形成全局唯一执行保证”，再使用运行时指标、日志或最小复现检查“限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理”是否成立。
- C. 只增加机器资源或重启进程，以一次恢复结果代替对“多实例下进程内锁和本地限流无法形成全局唯一执行保证”的验证。
- D. 只检查代码是否能够编译，通过后便认定“限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理”在当前部署中必然成立。
查看答案与解析
正确答案B
“客户端超时重试产生重复命令”可能由多条路径造成，不能直接证明根因。合理顺序是先确认边界“多实例下进程内锁和本地限流无法形成全局唯一执行保证”，再以“限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理”组织证据。采用误区“配置 RateLimiter 后支付请求绝不会重复扣款”、盲目扩容或只看编译结果，都跳过了运行配置与真实调用路径，无法形成可复核的诊断结论。
139 评审业务幂等相关实现时，以下哪项判断不成立？
难度： 实战
- A. 限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理
- B. 多实例下进程内锁和本地限流无法形成全局唯一执行保证
- C. 配置 RateLimiter 后支付请求绝不会重复扣款
- D. 遇到“客户端超时重试产生重复命令”时，应把可观察证据与平台契约分开记录，再验证二者是否一致。
查看答案与解析
正确答案C
题目要求找出不成立的判断，“配置 RateLimiter 后支付请求绝不会重复扣款”正是业务幂等的典型误区。主规则“限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理”描述了实现应依赖的契约，边界“多实例下进程内锁和本地限流无法形成全局唯一执行保证”限制了结论的适用范围。生产场景还需要保留指标、日志、跟踪或转储等证据，不能因为一次成功或失败就反转稳定契约。
140 准备上线涉及业务幂等的改动时，哪项验收方案最完整？
难度： 实战
- A. 依据“配置 RateLimiter 后支付请求绝不会重复扣款”完成修改，只要本地运行一次成功就立即发布。
- B. 按照“限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理”修改代码，但不核对“多实例下进程内锁和本地限流无法形成全局唯一执行保证”或目标发布模式。
- C. 只验证“多实例下进程内锁和本地限流无法形成全局唯一执行保证”，实现仍继续依赖“配置 RateLimiter 后支付请求绝不会重复扣款”这一未经证明的假设。
- D. 依据“限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理”实现，在“多实例下进程内锁和本地限流无法形成全局唯一执行保证”成立的环境中验证，并为“客户端超时重试产生重复命令”保留可观测证据和回退条件。
查看答案与解析
正确答案D
完整验收必须同时覆盖规则、边界和生产证据：实现遵守“限流减少请求数量但不能替代业务幂等，重复请求仍需幂等键和持久化约束处理”，部署环境满足“多实例下进程内锁和本地限流无法形成全局唯一执行保证”，并能在“客户端超时重试产生重复命令”出现时定位和回退。其余方案分别依赖错误假设、遗漏环境验证或只检查边界却保留错误实现，均不能证明改动在生产环境中安全。