一、 消息通知的业务场景与分类电商系统中的消息通知是连接平台、商家、用户三者之间的关键桥梁。1.1 按业务场景分类场景典型事件接收方实时性要求交易通知下单成功、支付结果、发货提醒、物流更新买家秒级商家通知新订单、售后申请、库存预警商家秒级营销通知优惠券发放、活动预告、大促提醒用户分钟级系统通知账号安全、版本更新、违规警告用户/商家分钟级1.2 按推送渠道分类渠道特点适用场景站内信平台内查看留存性好所有通知的默认渠道短信高触达率但成本高交易核心节点下单、支付、发货小程序订阅消息微信生态内需用户授权交易通知、物流更新APP推送需安装APP支持富媒体营销活动、大促提醒邮件成本低国际通用账单、营销邮件、密码重置二、 整体架构┌─────────────────────────────────────────────────────────────────┐ │ 业务触发层 │ │ 下单 → 支付 → 发货 → 售后 → 营销活动 → 系统告警 │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 消息路由层 │ │ ├─ 场景识别事件 → 需要发送哪些通知 │ │ ├─ 渠道选择优先级/用户偏好/渠道状态 │ │ └─ 模板匹配根据不同渠道选择对应模板 │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 消息队列层RocketMQ/Kafka │ │ ├─ 交易队列高优先级 │ │ ├─ 营销队列低优先级可降级 │ │ └─ 系统队列 │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 发送执行层异步消费者 │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ 站内信 │ │ 短信 │ │ 小程序 │ │ APP推送 │ │ │ │ 消费者 │ │ 消费者 │ │ 消费者 │ │ 消费者 │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 外部服务商 │ │ 阿里云短信 │ 微信小程序 │ 极光推送 │ SendGrid邮件 │ └─────────────────────────────────────────────────────────────────┘三个核心设计原则异步化通知发送不阻塞主业务流程可靠性消息不丢失发送失败可重试可降级高负载时优先保证核心交易通知三、 消息模板与渠道路由3.1 模板配置化sqlCREATE TABLE message_template ( id bigint PRIMARY KEY, scene_code varchar(50) NOT NULL, -- order:paid / order:shipped channel varchar(20) NOT NULL, -- in_app / sms / mini_program title_template varchar(200), content_template text, -- 支持变量占位: ${orderNo} template_id varchar(100) DEFAULT NULL -- 第三方平台模板ID ); INSERT INTO message_template VALUES (1, order:paid, in_app, 订单支付成功, 您的订单${orderNo}已支付成功共${itemCount}件商品合计${totalAmount}元, NULL), (2, order:paid, sms, NULL, 【商城】订单${orderNo}支付成功查看详情${detailUrl}, SMS_123456), (3, order:shipped, in_app, 订单已发货, 您的订单${orderNo}已发货物流单号${trackingNo}, NULL);3.2 渠道路由策略不同业务场景对不同渠道有优先级要求且需要支持用户自定义偏好。javapublic class ChannelRouter { public ListString selectChannels(String scene, String userId) { // 1. 从用户偏好获取设置 UserChannelPreference pref getPreference(userId); // 2. 场景偏好决定最终渠道 switch (scene) { case order:paid: // 交易核心短信站内信APP推送按优先级 return new ArrayList(List.of(sms, in_app, app_push)); case order:shipped: // 物流小程序订阅消息站内信 return List.of(mini_program, in_app); case marketing:coupon: // 营销仅APP推送站内信不发送短信降低成本 if (pref.isMarketingPush()) { return List.of(app_push, in_app); } return List.of(in_app); default: return List.of(in_app); } } }3.3 渠道降级策略核心原则高优先级的交易通知必须送达当某个渠道不可用时自动降级到备用渠道。javaComponent public class MessageSender { public void send(MessageTask task) { ListString channels router.selectChannels(task.getScene(), task.getUserId()); for (String channel : channels) { try { // 发送成功 → 记录日志 → 结束 doSend(channel, task); saveSuccessLog(task, channel); return; } catch (Exception e) { // 发送失败 → 记录失败日志 → 尝试下一渠道 saveFailLog(task, channel, e); log.warn(渠道{}发送失败降级到下一渠道, channel); } } // 所有渠道失败 → 记录最终失败人工介入 saveFinalFail(task); alertService.send(消息发送最终失败taskId task.getId()); } }四、 消息可靠投递4.1 消息生命周期[业务发送] → [存入待发送表] → [发送中] → [发送成功/失败] ↑ ↓ └── [重试队列] ←───────┘4.2 待发送表设计sqlCREATE TABLE outbox_message ( id bigint PRIMARY KEY AUTO_INCREMENT, message_id varchar(64) NOT NULL, scene_code varchar(50) NOT NULL, user_id varchar(32) NOT NULL, channels varchar(100) NOT NULL, -- 渠道候选列表 params json NOT NULL, -- 模板变量 status varchar(20) DEFAULT PENDING, -- PENDING / SENT / FAILED / FINAL_FAILED retry_count int DEFAULT 0, next_retry_time datetime DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status_retry (status, next_retry_time), KEY idx_user_id (user_id) );4.3 本地消息表 定时重试javaService public class ReliableMessageService { // 业务发送接口事务内写入 Transactional public void sendReliable(MessageRequest request) { // 1. 执行业务操作如下单 orderService.createOrder(request.getOrder()); // 2. 在同一事务中写入待发送消息 OutboxMessage msg new OutboxMessage(); msg.setMessageId(UUID.randomUUID().toString()); msg.setSceneCode(request.getScene()); msg.setUserId(request.getUserId()); msg.setParams(JSON.toJSONString(request.getParams())); outboxRepository.save(msg); // 事务提交后MQ异步触发真正的发送 // 如果MQ不可用定时任务兜底 } // 定时扫描重试每10秒 Scheduled(fixedDelay 10000) public void retryPendingMessages() { ListOutboxMessage pending outboxRepository.findPending( LocalDateTime.now(), 100 ); for (OutboxMessage msg : pending) { try { // 发送消息 sender.send(msg); msg.setStatus(SENT); outboxRepository.save(msg); } catch (Exception e) { msg.setRetryCount(msg.getRetryCount() 1); // 指数退避2^n 分钟 long delay (long) Math.pow(2, msg.getRetryCount()); msg.setNextRetryTime(LocalDateTime.now().plusMinutes(delay)); if (msg.getRetryCount() 10) { msg.setStatus(FINAL_FAILED); alertService.send(消息最终失败: msg.getId()); } outboxRepository.save(msg); } } } }五、 消息去重与频控5.1 去重机制业务场景同一笔订单支付成功后支付渠道可能推送多次回调避免重复发送通知。javaComponent public class MessageDeduplicator { // 基于Redis缓存防止短时间内重复发送 public boolean isDuplicate(String messageId, String scene, String userId) { String key msg:dedup: messageId : scene : userId; Boolean success redis.setIfAbsent(key, 1, Duration.ofMinutes(5)); return Boolean.FALSE.equals(success); } }5.2 频控机制保护下游渠道短信网关、推送服务同时也是控制成本的手段。javaComponent public class RateLimiterService { // 用户维度频控同一用户每分钟最多5条 public boolean checkUserRate(String userId) { String key msg:rate:user: userId; Long count redis.incr(key); if (count 1) { redis.expire(key, 60); } return count 5; } // 渠道维度频控短信每分钟最多1000条 public boolean checkChannelRate(String channel) { String key msg:rate:channel: channel; Long count redis.incr(key); if (count 1) { redis.expire(key, 60); } return count 1000; } }六、 踩坑实录坑1短信发送阻塞主流程现象用户下单后页面卡住3秒才返回。查看日志发现短信发送占用2.5秒。根因短信发送是同步的且用了串行HTTP调用。解决方案消息发送全量异步化使用消息队列主流程只写入本地消息表立即返回消费者独立处理发送坑2营销消息在促销高峰堵塞交易消息现象大促期间营销队列积压了大量消息导致交易通知订单支付成功短信延迟了20分钟才发送。根因所有消息在同一队列中没有按优先级隔离。解决方案分队列隔离交易队列高优先级专属消费者、营销队列低优先级可降级交易队列消费者数量是营销队列的2倍yaml# RocketMQ 队列配置 transaction-queue: topic: order-msg-topic consumer-group: order-msg-consumer concurrency: 8 # 高并发 marketing-queue: topic: marketing-msg-topic consumer-group: marketing-msg-consumer concurrency: 3 # 低并发大促时可降级为1坑3用户投诉收到了另一个商家的消息现象商家A的员工收到了商家B的订单通知。根因多租户场景下消息发送时没有携带tenant_id或消费者没有按租户隔离。解决方案所有消息携带tenant_id发送前校验当前用户是否属于该租户数据隔离延伸到消息层面java// 消息上下文 public class MessageContext { private String tenantId; private String userId; // 发送前校验 public void validate() { if (!tenantService.isUserInTenant(userId, tenantId)) { throw new SecurityException(用户不属于该租户); } } }七、 总结设计维度核心原则实现方式异步化通知不阻塞主流程本地消息表 MQ可靠投递消息不丢失失败可重试待发送表 定时重试 指数退避渠道路由场景匹配渠道按优先级降级模板配置 渠道选择 降级策略去重频控避免重复发送保护下游Redis缓存 多维度限流租户隔离不同租户消息绝对隔离tenant_id全链路传递文末思考消息通知系统的设计本质是在用户体验、运营效率、成本控制三者之间找平衡。交易通知走短信体验好但成本高营销通知走APP推送成本低但触达率有限这种分层策略本身就是一种架构取舍。
一、 消息通知的业务场景与分类电商系统中的消息通知是连接平台、商家、用户三者之间的关键桥梁。1.1 按业务场景分类场景典型事件接收方实时性要求交易通知下单成功、支付结果、发货提醒、物流更新买家秒级商家通知新订单、售后申请、库存预警商家秒级营销通知优惠券发放、活动预告、大促提醒用户分钟级系统通知账号安全、版本更新、违规警告用户/商家分钟级1.2 按推送渠道分类渠道特点适用场景站内信平台内查看留存性好所有通知的默认渠道短信高触达率但成本高交易核心节点下单、支付、发货小程序订阅消息微信生态内需用户授权交易通知、物流更新APP推送需安装APP支持富媒体营销活动、大促提醒邮件成本低国际通用账单、营销邮件、密码重置二、 整体架构┌─────────────────────────────────────────────────────────────────┐ │ 业务触发层 │ │ 下单 → 支付 → 发货 → 售后 → 营销活动 → 系统告警 │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 消息路由层 │ │ ├─ 场景识别事件 → 需要发送哪些通知 │ │ ├─ 渠道选择优先级/用户偏好/渠道状态 │ │ └─ 模板匹配根据不同渠道选择对应模板 │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 消息队列层RocketMQ/Kafka │ │ ├─ 交易队列高优先级 │ │ ├─ 营销队列低优先级可降级 │ │ └─ 系统队列 │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 发送执行层异步消费者 │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ 站内信 │ │ 短信 │ │ 小程序 │ │ APP推送 │ │ │ │ 消费者 │ │ 消费者 │ │ 消费者 │ │ 消费者 │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 外部服务商 │ │ 阿里云短信 │ 微信小程序 │ 极光推送 │ SendGrid邮件 │ └─────────────────────────────────────────────────────────────────┘三个核心设计原则异步化通知发送不阻塞主业务流程可靠性消息不丢失发送失败可重试可降级高负载时优先保证核心交易通知三、 消息模板与渠道路由3.1 模板配置化sqlCREATE TABLE message_template ( id bigint PRIMARY KEY, scene_code varchar(50) NOT NULL, -- order:paid / order:shipped channel varchar(20) NOT NULL, -- in_app / sms / mini_program title_template varchar(200), content_template text, -- 支持变量占位: ${orderNo} template_id varchar(100) DEFAULT NULL -- 第三方平台模板ID ); INSERT INTO message_template VALUES (1, order:paid, in_app, 订单支付成功, 您的订单${orderNo}已支付成功共${itemCount}件商品合计${totalAmount}元, NULL), (2, order:paid, sms, NULL, 【商城】订单${orderNo}支付成功查看详情${detailUrl}, SMS_123456), (3, order:shipped, in_app, 订单已发货, 您的订单${orderNo}已发货物流单号${trackingNo}, NULL);3.2 渠道路由策略不同业务场景对不同渠道有优先级要求且需要支持用户自定义偏好。javapublic class ChannelRouter { public ListString selectChannels(String scene, String userId) { // 1. 从用户偏好获取设置 UserChannelPreference pref getPreference(userId); // 2. 场景偏好决定最终渠道 switch (scene) { case order:paid: // 交易核心短信站内信APP推送按优先级 return new ArrayList(List.of(sms, in_app, app_push)); case order:shipped: // 物流小程序订阅消息站内信 return List.of(mini_program, in_app); case marketing:coupon: // 营销仅APP推送站内信不发送短信降低成本 if (pref.isMarketingPush()) { return List.of(app_push, in_app); } return List.of(in_app); default: return List.of(in_app); } } }3.3 渠道降级策略核心原则高优先级的交易通知必须送达当某个渠道不可用时自动降级到备用渠道。javaComponent public class MessageSender { public void send(MessageTask task) { ListString channels router.selectChannels(task.getScene(), task.getUserId()); for (String channel : channels) { try { // 发送成功 → 记录日志 → 结束 doSend(channel, task); saveSuccessLog(task, channel); return; } catch (Exception e) { // 发送失败 → 记录失败日志 → 尝试下一渠道 saveFailLog(task, channel, e); log.warn(渠道{}发送失败降级到下一渠道, channel); } } // 所有渠道失败 → 记录最终失败人工介入 saveFinalFail(task); alertService.send(消息发送最终失败taskId task.getId()); } }四、 消息可靠投递4.1 消息生命周期[业务发送] → [存入待发送表] → [发送中] → [发送成功/失败] ↑ ↓ └── [重试队列] ←───────┘4.2 待发送表设计sqlCREATE TABLE outbox_message ( id bigint PRIMARY KEY AUTO_INCREMENT, message_id varchar(64) NOT NULL, scene_code varchar(50) NOT NULL, user_id varchar(32) NOT NULL, channels varchar(100) NOT NULL, -- 渠道候选列表 params json NOT NULL, -- 模板变量 status varchar(20) DEFAULT PENDING, -- PENDING / SENT / FAILED / FINAL_FAILED retry_count int DEFAULT 0, next_retry_time datetime DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status_retry (status, next_retry_time), KEY idx_user_id (user_id) );4.3 本地消息表 定时重试javaService public class ReliableMessageService { // 业务发送接口事务内写入 Transactional public void sendReliable(MessageRequest request) { // 1. 执行业务操作如下单 orderService.createOrder(request.getOrder()); // 2. 在同一事务中写入待发送消息 OutboxMessage msg new OutboxMessage(); msg.setMessageId(UUID.randomUUID().toString()); msg.setSceneCode(request.getScene()); msg.setUserId(request.getUserId()); msg.setParams(JSON.toJSONString(request.getParams())); outboxRepository.save(msg); // 事务提交后MQ异步触发真正的发送 // 如果MQ不可用定时任务兜底 } // 定时扫描重试每10秒 Scheduled(fixedDelay 10000) public void retryPendingMessages() { ListOutboxMessage pending outboxRepository.findPending( LocalDateTime.now(), 100 ); for (OutboxMessage msg : pending) { try { // 发送消息 sender.send(msg); msg.setStatus(SENT); outboxRepository.save(msg); } catch (Exception e) { msg.setRetryCount(msg.getRetryCount() 1); // 指数退避2^n 分钟 long delay (long) Math.pow(2, msg.getRetryCount()); msg.setNextRetryTime(LocalDateTime.now().plusMinutes(delay)); if (msg.getRetryCount() 10) { msg.setStatus(FINAL_FAILED); alertService.send(消息最终失败: msg.getId()); } outboxRepository.save(msg); } } } }五、 消息去重与频控5.1 去重机制业务场景同一笔订单支付成功后支付渠道可能推送多次回调避免重复发送通知。javaComponent public class MessageDeduplicator { // 基于Redis缓存防止短时间内重复发送 public boolean isDuplicate(String messageId, String scene, String userId) { String key msg:dedup: messageId : scene : userId; Boolean success redis.setIfAbsent(key, 1, Duration.ofMinutes(5)); return Boolean.FALSE.equals(success); } }5.2 频控机制保护下游渠道短信网关、推送服务同时也是控制成本的手段。javaComponent public class RateLimiterService { // 用户维度频控同一用户每分钟最多5条 public boolean checkUserRate(String userId) { String key msg:rate:user: userId; Long count redis.incr(key); if (count 1) { redis.expire(key, 60); } return count 5; } // 渠道维度频控短信每分钟最多1000条 public boolean checkChannelRate(String channel) { String key msg:rate:channel: channel; Long count redis.incr(key); if (count 1) { redis.expire(key, 60); } return count 1000; } }六、 踩坑实录坑1短信发送阻塞主流程现象用户下单后页面卡住3秒才返回。查看日志发现短信发送占用2.5秒。根因短信发送是同步的且用了串行HTTP调用。解决方案消息发送全量异步化使用消息队列主流程只写入本地消息表立即返回消费者独立处理发送坑2营销消息在促销高峰堵塞交易消息现象大促期间营销队列积压了大量消息导致交易通知订单支付成功短信延迟了20分钟才发送。根因所有消息在同一队列中没有按优先级隔离。解决方案分队列隔离交易队列高优先级专属消费者、营销队列低优先级可降级交易队列消费者数量是营销队列的2倍yaml# RocketMQ 队列配置 transaction-queue: topic: order-msg-topic consumer-group: order-msg-consumer concurrency: 8 # 高并发 marketing-queue: topic: marketing-msg-topic consumer-group: marketing-msg-consumer concurrency: 3 # 低并发大促时可降级为1坑3用户投诉收到了另一个商家的消息现象商家A的员工收到了商家B的订单通知。根因多租户场景下消息发送时没有携带tenant_id或消费者没有按租户隔离。解决方案所有消息携带tenant_id发送前校验当前用户是否属于该租户数据隔离延伸到消息层面java// 消息上下文 public class MessageContext { private String tenantId; private String userId; // 发送前校验 public void validate() { if (!tenantService.isUserInTenant(userId, tenantId)) { throw new SecurityException(用户不属于该租户); } } }七、 总结设计维度核心原则实现方式异步化通知不阻塞主流程本地消息表 MQ可靠投递消息不丢失失败可重试待发送表 定时重试 指数退避渠道路由场景匹配渠道按优先级降级模板配置 渠道选择 降级策略去重频控避免重复发送保护下游Redis缓存 多维度限流租户隔离不同租户消息绝对隔离tenant_id全链路传递文末思考消息通知系统的设计本质是在用户体验、运营效率、成本控制三者之间找平衡。交易通知走短信体验好但成本高营销通知走APP推送成本低但触达率有限这种分层策略本身就是一种架构取舍。
