「上课前1小时提醒家长」——这句产品需求背后藏着一整个推送系统的架构决策。这篇拆解学页消息引擎的设计思路。一、需求比想象中复杂拆开「课前提醒」这一个场景提醒对象在学员时区迪拜学员和北京学员的「提前1小时」是不同时刻触达渠道按配置分流APP推送/短信/邮件家长可自选失败要重试推送服务偶尔抽风绝不能重复发家长收到两条相同提醒投诉二、架构分四层设计第1层触发调度层定时任务扫描「未来1小时内的课表」——关键设计按学员时区计算触发时刻而不是服务器时间。夏令时切换日单独做兼容处理这个坑踩过才懂。第2层消息队列层触发后先入队RabbitMQ不直接发。好处三个削峰开课高峰期提醒量瞬间放大、解耦新增渠道不影响主流程、可重试消费失败自动重回队列设最大重试3次。第3层渠道适配层每个渠道一个适配器APP推送/短信/邮件/企微统一接口。渠道选择尊重用户配置降级策略APP推送失败自动降级短信仅紧急类消息。第4层幂等与追踪层每条消息带唯一ID消费端幂等校验发过直接跳过——这是「不重复发」的保险丝。全链路日志留存家长说「没收到」时可完整回溯。三、一个生产数据的参考某3000学员机构日均消息量课前提醒2500条课务变动800条营销触达1200条。高峰开学首日单日消息量1.8万条——队列削峰后推送服务CPU峰值仅35%。四、三条设计原则1️⃣ 能队列不直发同步发送是可用性杀手2️⃣ 幂等是底线重复推送对信任的伤害是致命的3️⃣ 可回溯是责任出问题能在5分钟内定位到某条消息的全生命周期学页消息引擎支持多渠道、多时区、幂等推送教培场景开箱即用。欢迎技术同行评论区切磋
