为在平台稳定发送短信，应实施分层限流策略：全局限额与业务线配额并细化至应用、接口与手机号码维度；采用令牌桶或漏桶允许短时突发并保证长时平滑；关键通知独立配额并优先处理；监控TPS、延时、成功率及错误分布并触发告警和自动限级调整。指数退避与重试次数限制；排队与削峰策略配合；日志与回放用于事故演练及优化。
先搞清楚：为什么要对短信做限流
把限流想象成水管阀门。短信服务是那股水流，流量突然增大时如果不关阀门，管道会炸裂：网关被打满、运营商封号、回执延迟、成本暴涨。限流不是把人挡在门外，而是把流量按优先级和节奏分配，让系统活得久一点，业务能降级而不是崩溃。
限流的目标和基本原则
- 保障核心业务可用性：关键类短信（验证码、风控告警）要有独立配额或高优先级。
- 平滑输出，防止突发冲垮链路：允许短时突发，但长期平均保持在可承受范围。
- 公平与可控：不同业务线按策略分配资源，避免单个业务吃光池子。
- 可观测与可回滚：限流规则要能实时下发、回放和回滚。
限流的常见维度（你得同时考虑这几种）
全局（Global）
控制总体出站TPS，防止整个系统把运营商接口撑爆。通常由网关层或流量调度层实现，配合弹性伸缩策略。
业务线/应用（Tenant 或 App）
按客户或产品线划分配额，保证不同业务间的隔离。比如营销类和交易类要分开配额。
接口/模板级别
单个接口或短信模板可能被滥用，建议对模板频次设限，尤其是带链路或短链的模板。
手机号/号码簿（Per-recipient）
对同一手机号做频次限制，防刷、防骚扰也保护用户体验（避免短时间内收到大量短信）。
运营商/通道
不同通道能力不同，通道限流能避免某个通道过载导致“大面积失败”。
常用限流算法：原理与适用场景
下面把几种算法捋一遍，简单、实用、该用就用。
- 固定时间窗口（Fixed window）：每个时间窗口计数，超过阈值拒绝。实现简单，但容易在窗口边缘出现突发放行。
- 滑动窗口（Sliding window）：用更细粒度的计数减少边缘问题，精度高但实现复杂度上升。
- 令牌桶（Token Bucket）：按照速率生成令牌，发送需要消费令牌，允许突发。适用于需要保留短时突发能力的场景。
- 漏桶（Leaky Bucket）：控制输出速率，突发请求会被排队或丢弃，更偏向平滑输出。
- 滑动日志（Sliding log）：记录请求时间戳，精确但内存、存储开销高。
| 算法 | 优点 | 缺点 | 适用场景 |
| 固定窗口 | 实现简单，开销小 | 窗口锋利，边界突发 | 对延迟不敏感的非关键流量 |
| 滑动窗口 | 平滑边界，更准确 | 实现复杂，状态维护成本高 | 需精确计数的场景 |
| 令牌桶 | 允许突发，平滑长期速率 | 需定期发放令牌，分布式同步复杂 | 短信发送中常用，支持爆发 |
| 漏桶 | 输出稳定 | 突发能力弱 | 对输出稳定性要求高 |
工程实现步骤（一步步来）
1. 需求拆解与配额设计
先把业务分级：哪些是必须到达的（验证码、支付通知）、哪些是可延迟或降级的（营销短信）。按级别分配默认配额，再留出弹性池用于短时放量。
2. 选择合适的限流点
常见位置：接入层（最外层快速拦截）、网关层（集中调度）、发送层（细粒度模板/手机号限流）。最好是“多层防护”，不是单点。
3. 算法落地与分布式一致性
单机环境使用内存计数器或本地令牌桶，分布式环境可以用Redis（计数器、Lua脚本、基于令牌的实现）、或者专用限流服务。注意时钟漂移、原子操作与网络抖动带来的误差。
4. 优雅降级与排队策略
当达到限流阈值，优先做三件事：1）按优先级放行重要请求；2）对可延迟请求排队并实施后端异步发送；3）对于无价值请求直接拒绝并返回明确错误码给上游。
5. 失败重试与指数退避
不要简单无限制重试。建议按业务类型设置重试上限（例如验证码 2 次、通知 3 次），并且采用指数退避（初始延迟 x，乘以系数），同时对失败码做分类处理（比如运营商限速 VS 号码无效）。
监控与告警：你需要看什么
- TPS（每秒请求数）与出站TPS：结合限流阈值确认是否触发。
- 成功率与各类错误码比例：明确是通道问题、号码问题还是限流引起的拒绝。
- 延时分布（P50/P95/P99）：高延时可能意味着队列堆积或上游拥塞。
- 队列长度与池子使用率：固定阈值触发自动伸缩或告警。
- 配额使用趋势：按业务线、接口、手机号汇总历史消耗，支持预警和配额调整。
规则下发与动态调整（怎么灵活管）
把限流规则做成配置层，支持按策略下发到各个节点。关键要求：
- 规则实时下发且生效有回滚机制；
- 规则支持按时间窗口、按业务、按地域调节；
- 提供灰度发布能力，先在小流量上验证再全量推送。
典型策略示例（拿来就能用的配置模板）
- 验证码类：全局每手机每分钟不超过1条，每小时不超过5条；业务配额高优先；重试最多2次，间隔采用指数退避。
- 风控/告警：独立通道+独立配额，优先级最高，允许短时突发上限较大。
- 营销类：使用低优先级配额，支持限速队列和按小时窗限量，失败不可无限重试。
- 模板敏感度：带链接或验证码的模板单独限流，避免被运营商识别为垃圾短信。
常见问题与实践建议（别踩坑）
- 分布式计数一致性：避免简单用多节点本地计数器做全局限流。推荐使用Redis原子脚本或一致性服务。
- 阈值设置过保守：会影响业务转化。建议在非高峰期做流量回放，基于历史数据做阈值评估。
- 告警噪声太多：用多级告警和抑制策略，只有关键指标持续异常才上报到值班人员。
- 运营商策略变化：运营商会不定期调整路由或限速策略，保持通道级指标监控并准备备选通道。
演练与回放：把规则当武器练习
日常演练很重要。对历史高峰流量做回放，验证限流规则是否按预期工作；对故障场景（通道降级、数据库慢、网络抖动）做演练，确认降级链路、告警和自动扩容流程是否可靠。
小结性提醒（像朋友唠叨几句）
限流不是一劳永逸的东西，要随着业务、通道和用户行为变化持续调整。把规则做成可配置、可下发、可回放的组件，把监控覆盖到位，再做常态化演练。这样，遇到流量暴涨时你不会手忙脚乱，反而能优雅地把流量慢慢“筛”过去，让重要消息到达，让系统安稳运行。