在大厂面试中，面试题：如何设计一个千万级短信发送系统是考察高并发、高可用架构设计能力的经典题目。这类系统需同时应对日均千万级发送量、瞬时峰值QPS超10万、到达率99.99%以上的严苛要求，还要解决通道成本优化、防刷防盗刷、运营商限频等核心挑战。本文将从需求拆解、架构设计、核心技术到容灾方案，全面拆解千万级短信系统的设计要点，结合真实案例与技术选型，帮你在面试中展现从业务到底层的全链路设计能力，正如鳄鱼java在《分布式系统架构实战》中强调的："短信系统的本质，是在性能、成本与可靠性之间寻找动态平衡。"
需求分析：千万级短信系统的核心挑战
设计前需明确业务与技术指标，避免陷入"重技术轻业务"的误区。千万级短信系统需满足以下核心需求：
1. 业务需求：从功能到体验的全维度定义
- 发送场景：验证码（登录/注册）、通知短信（订单/物流）、营销短信（促销/活动），不同场景对时效性、到达率要求差异显著
- 量级指标：日均发送量1000万+，峰值QPS 10万+（如电商大促验证码场景），月峰值3亿+
- 质量要求：验证码短信99.99%到达率，5秒内送达；通知短信99.9%到达率，30秒内送达
- 成本控制：通道成本占比≤30%，支持多通道智能选路，优先使用高性价比通道
某电商平台双11数据显示：验证码短信超时1秒，用户注册转化率下降15%；通知短信到达率每降低0.1%，客服咨询量增加20%。
2. 技术挑战：四大核心矛盾的平衡
| 挑战类型 | 具体表现 | 技术指标 |
|---|---|---|
| 高并发写入 | 大促期间验证码请求瞬时峰值达日常50倍 | 支持10万QPS写入，响应时间<200ms |
| 高可用保障 | 通道故障、运营商限频、机房断电等异常 | 系统可用性99.99%，通道故障自动切换<1分钟 |
| 数据一致性 | 短信状态与业务系统同步，避免重复发送 | 状态同步延迟<5秒，重复发送率<0.01% |
| 合规与防刷 | 垃圾短信投诉、恶意刷取验证码、内容违规 | 投诉率<0.05%，异常请求拦截率>99% |
架构设计：分层解耦的高可用架构
采用"接入层-应用层-数据层-通道层"四层架构，通过异步化、缓冲化、可降级设计应对高并发与高可用需求。
1. 整体架构图与核心组件
业务系统 → API网关（限流/鉴权） → 短信接入服务 → Kafka消息队列
↓
应用层 → 短信处理服务（模板校验/黑名单过滤）、智能选路服务、状态回调服务
↓
数据层 → Redis（缓存/限流）、MySQL（分库分表）、MongoDB（日志存储）
↓
通道层 → 多运营商通道、第三方短信服务商、备用通道池
关键设计原则： - 异步优先：核心流程通过Kafka异步化，将同步请求转为异步处理，削峰填谷 - 无状态化：所有服务设计为无状态，支持水平扩容 - 多级缓冲：API网关缓冲→Kafka消息缓冲→通道发送队列缓冲，层层削峰
2. 核心服务拆分与职责
- 短信接入服务：接收业务系统发送请求，做基础参数校验与限流，写入Kafka
- 短信处理服务：消费Kafka消息，执行模板校验、变量替换、黑名单过滤
- 智能选路服务：基于通道质量（到达率/延迟）、成本、运营商归属地选择最优通道
- 状态回调服务：接收通道状态报告，更新短信状态，触发业务回调
- 监控告警服务：实时监控通道状态、发送成功率、延迟等核心指标
鳄鱼java技术团队建议：将短信接入服务与处理服务完全解耦，通过Kafka隔离，避免接入层流量冲击处理层。
核心技术点：从高并发到高可用的实现方案
1. 高并发写入：多级限流与异步削峰
千万级短信系统的首要挑战是应对瞬时流量峰值： - 接入层限流：API网关采用令牌桶算法，限制单IP/单用户QPS（如验证码短信单IP 60次/小时），结合Redis实现分布式限流
// Redis Lua脚本实现分布式限流
local key = "sms:limit:"..ARGV[1]
local count = redis.call('incr', key)
if count == 1 then redis.call('expire', key, ARGV[2]) end
return count
- 消息队列削峰：Kafka主题设置多分区（如32个），消费者组并行消费，将10万QPS峰值请求平摊至2万QPS处理能力
- 动态扩容：基于Kafka消息堆积量自动扩容处理服务实例，堆积量>100万时触发扩容
案例：某支付平台通过Kafka+动态扩容，将双11验证码峰值QPS从8万平稳处理，消息堆积量控制在50万以内。
2. 高可用保障：多通道容灾与智能选路
短信发送的可用性依赖通道稳定性，需构建多层容灾机制： - 多通道冗余：每个运营商（移动/联通/电信）至少对接2个通道，主备通道自动切换 - 智能选路算法：基于实时指标（近5分钟到达率、平均延迟、成本）动态评分，选择最优通道
通道评分 = 到达率(40%) + (1/延迟)(30%) + (1/成本)(30%)- 熔断降级：当某通道到达率<90%或超时率>5%时，自动熔断10分钟，期间请求路由至备用通道 - 本地缓存降级：Redis故障时，使用本地Caffeine缓存临时存储黑名单与限流计数，保障核心功能可用
鳄鱼java实测显示：多通道容灾可将系统可用性从99.9%提升至99.99%，年故障恢复时间缩短80%。
3. 数据一致性：状态同步与重试机制
短信状态（发送中/成功/失败）需与业务系统实时同步，避免数据不一致： - 状态回调处理：通道状态报告通过HTTP回调异步通知，使用幂等设计（基于msgId去重） - 定时重试队列：失败短信进入分级重试队列，按失败原因设置重试策略（如运营商忙：10s/30s/1min后重试3次） - 最终一致性保障：通过定时任务对比发送记录与状态报告，对超时未回调的短信主动查询通道状态
防作弊与合规：从内容到行为的全
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权百度百家发表，未经许可，不得转载。
