为什么要同时管并发和速率
并发数决定一批任务同时动手的数量，速率决定单位时间内发起多少次请求。两者管的不是同一件事：并发高但速率低时任务排队等待；速率高但并发低时下游可能被突发请求淹没。真实环境里，被拖垮的往往不是被管节点，而是共享依赖——数据库连接池、注册中心、统一授权服务。因此并发与限速要从「整条链路最脆弱的一环」倒推。
基本信息
| 并发控制 | 同时执行的目标数量上限 |
|---|---|
| 速率控制 | 单位时间内发起的请求或任务数量上限 |
| 批次控制 | 把目标分成若干批，批之间串行或间隔执行 |
| 重试控制 | 退避间隔与最大重试次数 |
典型限速做法
- 按批次执行：把目标分成若干组，组内并发、组间串行并留间隔。
- 限制最大并发：设置并发上限，超出部分排队而不是直接失败。
- 指数退避重试：失败后按倍数延长等待，避免对已过载的服务持续加压。
- 错峰调度：把大范围任务排到业务低峰，并避开其他批量作业的时间窗。
- 给共享依赖留量：数据库连接、授权服务调用等设置独立限值，不与批量任务争抢。
控制手段与副作用
| 手段 | 解决的问题 | 副作用 |
|---|---|---|
| 提高并发 | 单轮耗时长 | 下游被打满，失败率上升 |
| 降低并发 | 稳定性变好 | 变更窗口可能不够 |
| 分批执行 | 控制影响面 | 整轮时间拉长，跨批状态需关注 |
| 指数退避 | 避免重试风暴 | 总耗时不可预测 |
| 错峰调度 | 避开业务高峰 | 与人工临时变更冲突 |
并发参数宁可先保守再逐步放开：从较低值开始，观察失败率、目标节点负载与执行时长三项指标，确认稳定后再逐档提高，比一次性调到高值更容易定位拐点。
重试策略与限速要一起设计：高并发加立即重试会把瞬时故障放大成雪崩，尤其是在被管节点已经过载的情况下。