前言

通知推送广泛存在于支付成功、审批提醒、告警通知、营销触达、系统消息等场景。面试常问：

  • 短信发送失败怎么办。
  • 多渠道推送怎么设计。
  • 模板参数怎么管理。
  • 重复通知怎么防。
  • 如何统计送达率。

通知链路

flowchart TD
    A[业务事件] --> B[通知中心]
    B --> C[模板渲染]
    C --> D{选择渠道}
    D --> E[短信]
    D --> F[邮件]
    D --> G[站内信]
    D --> H[App Push]
    E --> I[发送结果记录]

通知中心设计

通知中心建议独立出来，避免每个业务系统直接对接短信和邮件供应商。

核心能力：

  • 模板管理。
  • 渠道管理。
  • 发送记录。
  • 失败重试。
  • 限流。
  • 黑名单。
  • 触达统计。

同步还是异步

同步发送

适合验证码等强实时场景。

缺点是依赖第三方响应。

异步发送

适合订单通知、审批提醒、营销消息。

优点：

  • 不阻塞业务主链路。
  • 可重试、可削峰。

常见做法：

  • 业务系统发通知事件到 MQ。
  • 通知中心消费并发送。

多渠道降级

例如短信供应商 A 失败，可以切到供应商 B；App Push 失败可以补站内信。

降级要点：

  • 配置渠道优先级。
  • 记录失败原因。
  • 控制重试次数。
  • 避免重复触达。

模板管理

模板应支持：

  • 模板编码。
  • 模板内容。
  • 参数列表。
  • 渠道差异。
  • 审核状态。
  • 版本管理。

示例：

1
订单 {orderNo} 已支付成功，金额 {amount} 元。

幂等和频控

通知重复会影响用户体验，甚至产生资费浪费。

常见幂等键：

1
biz_type + biz_no + channel + receiver

频控维度：

  • 用户。
  • 手机号。
  • IP。
  • 模板。
  • 渠道。

高频面试题

为什么通知要独立成中心？

为了统一模板、渠道、限流、重试和统计，避免业务系统重复对接供应商。

短信失败怎么办？

可以重试、切换供应商、降级为其他渠道，并记录失败原因。

通知重复怎么防？

用业务唯一键做幂等，同时限制发送频率。

验证码和普通通知有什么区别？

验证码实时性更强，通常同步或准同步；普通通知更适合异步。

总结

通知推送系统的重点是统一接入、多渠道、模板化、可重试、可降级、可统计。企业落地时要把通知从业务主链路中解耦出来，同时保证重要通知有补偿能力。