ASP.NET Core 试题 33：速率限制
0641 在 固定窗口限流 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 固定窗口能在任意滑动时间段内保证请求数绝不超过上限
- B. 容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值
- C. 固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发
- D. 观察到“两个窗口交界处出现双倍突发”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 固定窗口限流 的主规则：固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发。选项“容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值”是使用规则时要验证的边界，不是规则本身；“固定窗口能在任意滑动时间段内保证请求数绝不超过上限”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0642 两个窗口交界处出现双倍突发。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“固定窗口能在任意滑动时间段内保证请求数绝不超过上限”定性，不再检查配置、身份或运行时证据。
- B. 先验证“容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值”，再依据“固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值”。
- D. 以一次成功请求作为结论，不再确认“固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发”是否成立。
查看答案与解析
正确答案B
场景“两个窗口交界处出现双倍突发”指向 固定窗口限流，但症状本身不能证明根因。正确排查应先确认边界“容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值”，再用主规则“固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发”解释证据。直接采用误区“固定窗口能在任意滑动时间段内保证请求数绝不超过上限”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0643 关于 固定窗口限流，以下哪项说法不成立？
难度： 实战
- A. 固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发
- B. 容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值
- C. 出现“两个窗口交界处出现双倍突发”时，应收集证据并同时核对主规则与适用边界。
- D. 固定窗口能在任意滑动时间段内保证请求数绝不超过上限
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“固定窗口能在任意滑动时间段内保证请求数绝不超过上限”正是 固定窗口限流 的典型误区。其余三项分别给出了主规则“固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发”、适用边界“容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0644 针对“两个窗口交界处出现双倍突发”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发”修正实现，并用测试或遥测验证“容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值”。
- B. 按“固定窗口能在任意滑动时间段内保证请求数绝不超过上限”修改实现，并把一次请求成功作为验收结果。
- C. 按“固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发”修改代码后直接上线，不验证“容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值”。
- D. 只验证“容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值”，但实现仍继续依赖“固定窗口能在任意滑动时间段内保证请求数绝不超过上限”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：固定窗口在每个固定时间段内允许一定数量许可，实现简单但窗口边界可能突发；并确认 容量和窗口应按端点成本与客户端行为设置，不能只按全站平均值。继续接受“固定窗口能在任意滑动时间段内保证请求数绝不超过上限”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“两个窗口交界处出现双倍突发”这一生产场景能否安全上线。
0645 在 滑动窗口限流 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 滑动窗口不保存任何状态且适合无限基数键
- B. 分段数增加会提高状态和计算成本，仍需选择合适分区键
- C. 观察到“按用户限流导致内存持续增长”即可把一次现象当成完整框架契约。
- D. 滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑
查看答案与解析
正确答案D
正确答案直接描述 滑动窗口限流 的主规则：滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑。选项“分段数增加会提高状态和计算成本，仍需选择合适分区键”是使用规则时要验证的边界，不是规则本身；“滑动窗口不保存任何状态且适合无限基数键”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0646 按用户限流导致内存持续增长。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“滑动窗口不保存任何状态且适合无限基数键”定性，不再检查配置、身份或运行时证据。
- B. 先验证“分段数增加会提高状态和计算成本，仍需选择合适分区键”，再依据“滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“分段数增加会提高状态和计算成本，仍需选择合适分区键”。
- D. 以一次成功请求作为结论，不再确认“滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑”是否成立。
查看答案与解析
正确答案B
场景“按用户限流导致内存持续增长”指向 滑动窗口限流，但症状本身不能证明根因。正确排查应先确认边界“分段数增加会提高状态和计算成本，仍需选择合适分区键”，再用主规则“滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑”解释证据。直接采用误区“滑动窗口不保存任何状态且适合无限基数键”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0647 关于 滑动窗口限流，以下哪项说法不成立？
难度： 实战
- A. 滑动窗口不保存任何状态且适合无限基数键
- B. 滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑
- C. 分段数增加会提高状态和计算成本，仍需选择合适分区键
- D. 出现“按用户限流导致内存持续增长”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“滑动窗口不保存任何状态且适合无限基数键”正是 滑动窗口限流 的典型误区。其余三项分别给出了主规则“滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑”、适用边界“分段数增加会提高状态和计算成本，仍需选择合适分区键”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0648 针对“按用户限流导致内存持续增长”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“滑动窗口不保存任何状态且适合无限基数键”修改实现，并把一次请求成功作为验收结果。
- B. 按“滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑”修改代码后直接上线，不验证“分段数增加会提高状态和计算成本，仍需选择合适分区键”。
- C. 按“滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑”修正实现，并用测试或遥测验证“分段数增加会提高状态和计算成本，仍需选择合适分区键”。
- D. 只验证“分段数增加会提高状态和计算成本，仍需选择合适分区键”，但实现仍继续依赖“滑动窗口不保存任何状态且适合无限基数键”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：滑动窗口把窗口分段并回收过期段许可，使边界流量更平滑；并确认 分段数增加会提高状态和计算成本，仍需选择合适分区键。继续接受“滑动窗口不保存任何状态且适合无限基数键”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“按用户限流导致内存持续增长”这一生产场景能否安全上线。
0649 在 令牌桶 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 令牌按速率补充并允许一定突发，消费一个请求需要获取许可
- B. 令牌桶只限制同时执行请求数，不限制长期请求速率
- C. TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限
- D. 观察到“短时突发通过后长期速率仍被控制”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 令牌桶 的主规则：令牌按速率补充并允许一定突发，消费一个请求需要获取许可。选项“TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限”是使用规则时要验证的边界，不是规则本身；“令牌桶只限制同时执行请求数，不限制长期请求速率”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0650 短时突发通过后长期速率仍被控制。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“令牌桶只限制同时执行请求数，不限制长期请求速率”定性，不再检查配置、身份或运行时证据。
- B. 先验证“TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限”，再依据“令牌按速率补充并允许一定突发，消费一个请求需要获取许可”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限”。
- D. 以一次成功请求作为结论，不再确认“令牌按速率补充并允许一定突发，消费一个请求需要获取许可”是否成立。
查看答案与解析
正确答案B
场景“短时突发通过后长期速率仍被控制”指向 令牌桶，但症状本身不能证明根因。正确排查应先确认边界“TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限”，再用主规则“令牌按速率补充并允许一定突发，消费一个请求需要获取许可”解释证据。直接采用误区“令牌桶只限制同时执行请求数，不限制长期请求速率”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0651 关于 令牌桶，以下哪项说法不成立？
难度： 实战
- A. 令牌按速率补充并允许一定突发，消费一个请求需要获取许可
- B. TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限
- C. 出现“短时突发通过后长期速率仍被控制”时，应收集证据并同时核对主规则与适用边界。
- D. 令牌桶只限制同时执行请求数，不限制长期请求速率
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“令牌桶只限制同时执行请求数，不限制长期请求速率”正是 令牌桶 的典型误区。其余三项分别给出了主规则“令牌按速率补充并允许一定突发，消费一个请求需要获取许可”、适用边界“TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0652 针对“短时突发通过后长期速率仍被控制”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“令牌桶只限制同时执行请求数，不限制长期请求速率”修改实现，并把一次请求成功作为验收结果。
- B. 按“令牌按速率补充并允许一定突发，消费一个请求需要获取许可”修改代码后直接上线，不验证“TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限”。
- C. 按“令牌按速率补充并允许一定突发，消费一个请求需要获取许可”修正实现，并用测试或遥测验证“TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限”。
- D. 只验证“TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限”，但实现仍继续依赖“令牌桶只限制同时执行请求数，不限制长期请求速率”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：令牌按速率补充并允许一定突发，消费一个请求需要获取许可；并确认 TokenLimit 决定突发容量，补充率决定长期速率，不能混为并发上限。继续接受“令牌桶只限制同时执行请求数，不限制长期请求速率”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“短时突发通过后长期速率仍被控制”这一生产场景能否安全上线。
0653 在 并发限制 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 并发限制为 10 表示每分钟最多十个请求
- B. 并发限流限制同时处理的请求数，许可在请求完成后归还
- C. 它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时
- D. 观察到“快速请求每秒完成数百次”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 并发限制 的主规则：并发限流限制同时处理的请求数，许可在请求完成后归还。选项“它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时”是使用规则时要验证的边界，不是规则本身；“并发限制为 10 表示每分钟最多十个请求”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0654 快速请求每秒完成数百次。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时”，再依据“并发限流限制同时处理的请求数，许可在请求完成后归还”判断实现是否符合契约。
- B. 直接按“并发限制为 10 表示每分钟最多十个请求”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时”。
- D. 以一次成功请求作为结论，不再确认“并发限流限制同时处理的请求数，许可在请求完成后归还”是否成立。
查看答案与解析
正确答案A
场景“快速请求每秒完成数百次”指向 并发限制，但症状本身不能证明根因。正确排查应先确认边界“它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时”，再用主规则“并发限流限制同时处理的请求数，许可在请求完成后归还”解释证据。直接采用误区“并发限制为 10 表示每分钟最多十个请求”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0655 关于 并发限制，以下哪项说法不成立？
难度： 实战
- A. 并发限流限制同时处理的请求数，许可在请求完成后归还
- B. 它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时
- C. 并发限制为 10 表示每分钟最多十个请求
- D. 出现“快速请求每秒完成数百次”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“并发限制为 10 表示每分钟最多十个请求”正是 并发限制 的典型误区。其余三项分别给出了主规则“并发限流限制同时处理的请求数，许可在请求完成后归还”、适用边界“它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0656 针对“快速请求每秒完成数百次”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“并发限制为 10 表示每分钟最多十个请求”修改实现，并把一次请求成功作为验收结果。
- B. 按“并发限流限制同时处理的请求数，许可在请求完成后归还”修改代码后直接上线，不验证“它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时”。
- C. 只验证“它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时”，但实现仍继续依赖“并发限制为 10 表示每分钟最多十个请求”。
- D. 按“并发限流限制同时处理的请求数，许可在请求完成后归还”修正实现，并用测试或遥测验证“它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：并发限流限制同时处理的请求数，许可在请求完成后归还；并确认 它不限制单位时间请求总量，适合保护昂贵并发资源但需处理排队和超时。继续接受“并发限制为 10 表示每分钟最多十个请求”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“快速请求每秒完成数百次”这一生产场景能否安全上线。
0657 在 分区与队列 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 把原始任意 Header 当分区键不会产生状态增长风险
- B. PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序
- C. 分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟
- D. 观察到“攻击者不断更换键导致限流状态膨胀”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 分区与队列 的主规则：PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序。选项“分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟”是使用规则时要验证的边界，不是规则本身；“把原始任意 Header 当分区键不会产生状态增长风险”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0658 攻击者不断更换键导致限流状态膨胀。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“把原始任意 Header 当分区键不会产生状态增长风险”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟”。
- C. 以一次成功请求作为结论，不再确认“PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序”是否成立。
- D. 先验证“分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟”，再依据“PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“攻击者不断更换键导致限流状态膨胀”指向 分区与队列，但症状本身不能证明根因。正确排查应先确认边界“分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟”，再用主规则“PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序”解释证据。直接采用误区“把原始任意 Header 当分区键不会产生状态增长风险”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0659 关于 分区与队列，以下哪项说法不成立？
难度： 实战
- A. PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序
- B. 分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟
- C. 把原始任意 Header 当分区键不会产生状态增长风险
- D. 出现“攻击者不断更换键导致限流状态膨胀”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“把原始任意 Header 当分区键不会产生状态增长风险”正是 分区与队列 的典型误区。其余三项分别给出了主规则“PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序”、适用边界“分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0660 针对“攻击者不断更换键导致限流状态膨胀”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序”修正实现，并用测试或遥测验证“分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟”。
- B. 按“把原始任意 Header 当分区键不会产生状态增长风险”修改实现，并把一次请求成功作为验收结果。
- C. 按“PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序”修改代码后直接上线，不验证“分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟”。
- D. 只验证“分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟”，但实现仍继续依赖“把原始任意 Header 当分区键不会产生状态增长风险”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：PartitionedRateLimiter 可按用户、API Key、IP 或端点分区，队列可选择处理顺序；并确认 分区键必须受控，不能让攻击者制造无限分区；排队也会占资源并增加延迟。继续接受“把原始任意 Header 当分区键不会产生状态增长风险”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“攻击者不断更换键导致限流状态膨胀”这一生产场景能否安全上线。