Spring Boot 3 WebSocket集群推送：STOMP认证与消息中继实战

我把推送系统从单机搬到集群时被现实狠狠教育过一轮单机验证全通过前端也联调好了结果一上多节点用户经常收不到消息。排查到最后问题全集中在两个地方——握手阶段的Token认证没吃透以及默认的SimpleBroker压根不支持跨节点。这篇文章就把这套组合的完整落地过程写清楚包括STOMP选型、Token双重校验、集群下的消息中继方案以及我踩过的一些坑。适合正在用Spring Boot 3做实时通知、订单状态推送、站内信提醒这类“服务器单向推送”场景的团队参考。1. 为什么“服务器推消息”会同时卡在认证和集群上1.1 从一次线上事故说起去年我们做一个订单状态实时推送需求本身不复杂用户下单之后后端业务系统把支付结果、发货状态推给前端页面前端实时展示不刷新页面。听起来就是个典型WebSocket推送需求但我第一次用Spring Boot 3做的时候把它想简单了。单机开发环境一切正常本地起一个服务前端连上就能收到消息。结果部署到测试环境两台实例问题立刻暴露用户A连到了节点1订单服务把消息发到了节点2节点2上根本没有这个用户的WebSocket连接消息直接丢弃。更隐蔽的是有些用户连接的时候带上了Token但重连之后Token没通过校验表现为偶发性的连接被服务端拒绝。两个问题叠加起来表现就是“有时候能收到有时候收不到刷新一下又好了”。这个事故其实暴露了两个典型问题一是WebSocket连接的认证方式跟普通HTTP接口不一样不能简单复用Spring Security的过滤器链二是默认的消息代理是进程内内存版压根不具备跨节点分发能力。这两个问题不解决推送系统就不可能做到“可靠”。1.2 两个坎的本质原因先聊认证。WebSocket连接建立时客户端会发一个HTTP Upgrade请求服务端同意后协议才从HTTP切换成WebSocket。对于Spring Boot 3 Spring Security 6这套组合问题在于WebSocket协议升级之后后续传输的数据帧不再走Servlet过滤器链。也就是说你熟悉的SecurityContextHolder、Filter、Interceptor在WebSocket消息阶段默认是不直接生效的。如果只在普通HTTP接口上做了Token校验WebSocket连接本身可能完全没有经过身份验证。再聊集群。Spring Boot默认的SimpleBroker是基于内存的STOMP消息代理它在每个应用实例内部维护一份订阅关系。单机时所有客户端都连同一个实例消息自然能找到订阅者多机部署后负载均衡会把WebSocket连接分散到不同实例你在节点A上广播一条消息节点B上的客户端根本看不到。这是架构问题不是代码问题改业务逻辑没用必须在消息分发层解决。理解了这两点后面的技术选型和改造方向就清晰了认证得在WebSocket握手阶段和STOMP连接阶段分别把关消息分发需要引入跨节点的Broker或应用层广播机制。2. 技术选型轮询、SSE、裸WebSocket、STOMP我为什么最后选了STOMP2.1 四种方案对比做实时推送很多团队第一反应就是WebSocket。但WebSocket只是一个传输层协议它管不到“消息该发给谁”“客户端订阅了什么”这些事。我简单做过一个对比方案 | 优点 | 缺点 | 适合场景 轮询 | 实现简单兼容性最好 | 浪费带宽、延迟取决于轮询间隔 | 低频、无实时要求 SSE | 原生单向自动重连走HTTP | 只能服务端推客户端浏览器支持虽好但连接数受限 | 纯单向通知比如告警流 裸WebSocket | 全双工延迟低 | 没有消息格式规范心跳、订阅、鉴权全自己造 | 协议自由度要求极高 STOMP over WebSocket | 在WebSocket之上定义帧协议天然支持订阅、心跳、Ack | 比裸WebSocket多一层协议解析引入一定复杂度 | 需要多主题、点对点推送、消息代理参与的场景我这个项目需要的是“服务器单向推送”但客户端前端需要按业务类型订阅不同队列比如订单通知、系统公告、个人站内信。用裸WebSocket的话我得自己定义消息类型、自己实现订阅表、自己设计心跳和重连语义——这些STOMP已经帮你做好了。2.2 STOMP在WebSocket里的位置很多人对STOMP有误解觉得它是个重量级协议。其实STOMP全称是Simple Text Oriented Messaging Protocol本质就是一个基于文本的简单消息格式类似HTTP那样有方法、请求头、请求体。客户端跟服务端之间传输的是CONNECT、SUBSCRIBE、SEND、ACK这些帧。它运行在WebSocket之上WebSocket负责解决“长连接”和“全双工通信”STOMP负责解决“消息语义”——你订阅了哪个目的地消息该路由到哪个订阅者。打个比方WebSocket是高速公路STOMP是交规。没有交规的路也能跑车但多车交汇时怎么让行、怎么标识目的地就会乱套。用了STOMPSpring的SimpMessagingTemplate、SendTo、SendToUser这些抽象才派得上用场。2.3 什么时候不该用这套组合也不是什么场景都适合WebSocketSTOMP。如果推送频率很低比如每天几条公告用SSE甚至轮询都更省事因为WebSocket要维护长连接和心跳服务端连接数成本不低。如果消息量极大且要可靠持久化STOMP over WebSocket只是接入层底层还是需要RabbitMQ或Kafka这类消息中间件来扛此时更应该先想清楚消息中间件怎么选。我的判断标准是只有当“客户端需要实时感知服务端状态且需要按主题订阅区分消息类型”时STOMP才明显优于其他方案。如果只是简单的“有新数据就全量推一下”SSE就够了。3. Spring Boot 3工程搭建与依赖锁定3.1 JDK 17和jakarta命名空间Spring Boot 3.x的底线是JDK 17因为它基于Spring Framework 6整个代码库已经迁移到Jakarta EE命名空间javax.servlet变成了jakarta.servletjavax.persistence变成了jakarta.persistence。如果你是从Spring Boot 2.x老项目升级第一步就是全项目搜javax.*相关依赖尤其是内置Tomcat、Servlet API这块。我在这个项目里用的是Spring Boot 3.2.x后面又用3.3.x验证过没遇到兼容性问题。3.2 依赖清单Maven工程核心依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-websocket/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.security/groupId artifactIdspring-security-messaging/artifactId /dependencyspring-security-messaging这个依赖容易漏但很重要。它提供了Spring Security在STOMP消息通道上的集成能力没有它ChannelInterceptor里拿StompHeaderAccessor做消息级鉴权时很多消息头工具类用起来不顺手。如果Token本身是JWT解析库我推荐nimbus-jose-jwtSpring Security的OAuth2资源服务器就是基于它的。你也可以用jjwt但注意0.12版本API改动比较大网上很多老代码用的是0.9/0.11的写法直接复制容易报错。3.3 关于spring-cloud-starter-oauth2被废弃这件事热心网友搜到了spring boot3 spring-cloud-starter-oauth2废弃这里多说一句。Spring Cloud的spring-cloud-starter-oauth2在Spring Boot 3时代确实已经被打入冷宫因为它依赖的旧Spring Security OAuth2模块不再继续演进。如果你在网上搜到旧教程让你引入这个starter做Token认证请直接忽略。正确做法是引入spring-boot-starter-oauth2-resource-serverdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-oauth2-resource-server/artifactId /dependency不过如果你只是想在WebSocket握手时校验自签JWT不一定要引入完整的Resource Server。自己写一个JWT解析工具类就够了private Claims parseToken(String token) { SecretKey key Keys.hmacShaKeyFor(secretKey.getBytes(StandardCharsets.UTF_8)); return Jwts.parser() .verifyWith(key) .build() .parseSignedClaims(token) .getPayload(); }这套代码不依赖Spring Security的认证流程纯粹做签名校验和Claims提取放在握手拦截器里非常轻量。4. Token认证的正确姿势从握手拦截到STOMP CONNECT双重校验4.1 为什么认证不能只放在消息层WebSocket连接一旦建立理论上可以一直保持很久不会像HTTP请求那样频繁创建销毁。如果只在消息层校验Token攻击者可以先建立一个空连接不发任何消息这个连接就会白白占用服务端资源而且Token在长连接生命周期内可能过期过期后除非主动关闭否则连接还在。所以我坚持在握手阶段就把认证做掉。但握手认证通过不等于万事大吉。STOMP协议有自己的连接帧CONNECTSpring WebSocket上下文里网络连接和STOMP会话不是严格同步的。如果不在STOMP层设置Principal后续做convertAndSendToUser时Spring可能拿不到当前用户身份导致用户维度的消息推送失败。这就是为什么推荐做双重校验。4.2 第一道防线HandshakeInterceptor校验JWT实现一个HandshakeInterceptor在WebSocket握手前拦截Component public class TokenHandshakeInterceptor implements HandshakeInterceptor { private final JwtTokenValidator jwtTokenValidator; public TokenHandshakeInterceptor(JwtTokenValidator jwtTokenValidator) { this.jwtTokenValidator jwtTokenValidator; } Override public boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, MapString, Object attributes) { if (request instanceof ServletServerHttpRequest servletRequest) { String token servletRequest.getServletRequest().getParameter(token); String userId jwtTokenValidator.validateAndGetUserId(token); if (userId ! null) { attributes.put(userId, userId); return true; } } response.setStatusCode(HttpStatus.UNAUTHORIZED); return false; } Override public void afterHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Exception exception) { // 握手的收尾逻辑可以留空但方法不要删 } }这里attributes里的数据可以在WebSocketSession和后续STOMP处理里通过getSessionAttributes()拿到。校验失败时直接返回401这次握手就断了。4.3 第二道防线ChannelInterceptor校验CONNECT帧握手层做了校验STOMP层还得把用户身份放进去。实现一个ChannelInterceptor拦截客户端入站消息Configuration EnableWebSocketMessageBroker public class WebSocketBrokerConfig implements WebSocketMessageBrokerConfigurer { private final JwtTokenValidator jwtTokenValidator; public WebSocketBrokerConfig(JwtTokenValidator jwtTokenValidator) { this.jwtTokenValidator jwtTokenValidator; } Override public void configureClientInboundChannel(ChannelRegistration registration) { registration.interceptors(new ChannelInterceptor() { Override public Message? preSend(Message? message, MessageChannel channel) { StompHeaderAccessor accessor MessageHeaderAccessor.getAccessor(message, StompHeaderAccessor.class); if (accessor ! null StompCommand.CONNECT.equals(accessor.getCommand())) { String token accessor.getFirstNativeHeader(Authorization); String userId jwtTokenValidator.validateAndGetUserId(token); if (userId ! null) { ListGrantedAuthority authorities List.of(new SimpleGrantedAuthority(ROLE_USER)); accessor.setUser(new UsernamePasswordAuthenticationToken(userId, null, authorities)); } } return message; } }); } }这一步很多人踩坑握手拦截器里明明校验过Token了但没在STOMP CONNECT时设置Principal导致后续convertAndSendToUser(userId, ...)根本找不到目标用户。因为SimpleBroker的UserDestinationMessageHandler是根据STOMP会话的Principal来决定用户关联的。4.4 安全细节 Token放哪里最合适原生WebSocket的WebSocket构造函数不允许自定义Header所以浏览器环境下最常见的做法是把Token放在URL查询参数里ws://host/ws?tokenxxx。这样做能用但要注意查询参数会出现在Nginx或网关的访问日志里。Token泄漏的风险不是没有尤其在公网环境。我的推荐做法是分两步客户端先通过HTTP接口换取一个短时效的临时连接Token比如有效期5分钟然后用这个临时Token去连接WebSocket。这样即使日志里泄漏了攻击者能利用的时间窗口也很短。生产环境一定要用wss://协议别用ws://明文传输。还有跨域和CSRF这组配置别忽略。WebSocket不像表单请求那样能塞CSRF Token我建议直接禁用CSRF同时把跨域白名单收紧registry.addEndpoint(/ws) .setAllowedOriginPatterns(https://yourdomain.com) .addInterceptors(tokenHandshakeInterceptor);注意setAllowedOriginPatterns(*)虽然方便但生产环境不要图省事明确写上允许的域名列表更安全。5. 单机推送链路的完整实现5.1 最小的WebSocketSTOMP配置先给一个能跑通的配置。EnableWebSocketMessageBroker会启用STOMP消息代理Configuration EnableWebSocketMessageBroker public class WebSocketBrokerConfig implements WebSocketMessageBrokerConfigurer { Override public void configureMessageBroker(MessageBrokerRegistry registry) { registry.enableSimpleBroker(/topic, /queue); registry.setApplicationDestinationPrefixes(/app); registry.setUserDestinationPrefix(/user); } Override public void registerStompEndpoints(StompEndpointRegistry registry) { registry.addEndpoint(/ws) .setAllowedOriginPatterns(*) .addInterceptors(tokenHandshakeInterceptor); } }几个前缀的含义我敲一下黑板/topic广播主题所有订阅者都能收到。/queue点对点队列消息只会被一个订阅者消费。配合用户前缀时实际发送的目标是某个用户的私有队列。/app客户端往服务端发消息的目的地前缀。虽然我们主要做服务端推送但这个前缀要留着因为Ack确认等控制帧要走这里。/userSpring的用户目的地前缀客户端订阅时写/user/queue/notify服务端推送时用convertAndSendToUser。5.2 使用SimpMessagingTemplate主动推送核心推送代码其实非常简单在任意Spring管理的Service里注入SimpMessagingTemplateService public class OrderNotifyService { private final SimpMessagingTemplate messagingTemplate; public OrderNotifyService(SimpMessagingTemplate messagingTemplate) { this.messagingTemplate messagingTemplate; } public void notifyOrderStatus(String userId, OrderStatusMessage message) { messagingTemplate.convertAndSendToUser( userId, /queue/notify, message ); } }客户端订阅的时候用/user/queue/notify服务端推送时convertAndSendToUser会自动把/user前缀转换成该用户对应的实际队列。这个过程对前端是透明的。有一个细节容易踩坑广播Topic的命名不要带动态ID。比如订单状态变更有些同学会这么设计convertAndSend(/topic/order/ orderId, message)。这样做的问题是订单量一大Topic数量就会爆炸SimpleBroker需要为每个Topic维护订阅关系内存和路由开销都会上升。更好的做法是广播到/topic/order消息体里带上orderId客户端根据orderId判断是不是自己关心的订单。5.3 点对点推送与SendToUser的坑convertAndSendToUser在单机模式下很好用但有两点必须提前说清楚。第一同一个用户开多个浏览器标签页时每个标签页会建立独立的WebSocket会话。convertAndSendToUser默认是推给该用户所有活跃会话不是只推给某一个设备。如果需要精确到单个设备消息体里要带设备标识或sessionId客户端自行过滤。第二SendToUser注解不推荐在单向推送场景里过度依赖。我见过不少项目在方法上写SendToUser(/queue/notify)但这个方法本身处理的是客户端发来的MessageMapping请求。服务端没有主动触发入口时SendToUser形同虚设。单向推送最可控的方式就是直接用SimpMessagingTemplate.convertAndSendToUser调用时机完全由你控制想什么时候推就什么时候推。5.4 快速验证推送WebSocketStompClient集成测试单机联调时我不建议直接开浏览器。Spring Boot自带WebSocketStompClient可以写一个快速验证用例var client new WebSocketStompClient(new StandardWebSocketClient()); client.setMessageConverter(new MappingJackson2MessageConverter()); client.setDefaultHeartbeat(new long[]{10000, 10000}); StompSession session client .connectAsync(ws://localhost:8080/ws?tokentest-token, new StompSessionHandlerAdapter() {}) .get(5, TimeUnit.SECONDS); session.subscribe(/user/queue/notify, new StompFrameHandler() { Override public Type getPayloadType(StompHeaders headers) { return OrderStatusMessage.class; } Override public void handleFrame(StompHeaders headers, Object payload) { System.out.println(收到推送: payload); } }); // 模拟调用一次推送服务 orderNotifyService.notifyOrderStatus(user-1, new OrderStatusMessage(123, PAID));这个验证脚本跑通了再去写前端页面能省掉大量定位时间。6. 集群环境SimpleBroker为什么必挂消息中继又该怎么配6.1 集群中的三个典型故障我在生产中遇到并归纳了三类故障第一广播消息只发给了一部分订阅者。节点A上的Topic广播发不出去给节点B上的订阅者因为SimpleBroker对每个节点是孤立的。第二用户连接漂移。用户第一次连到了节点A断线重连时正好被负载均衡转发到节点B。如果服务端还按节点A的会话做推送必然失败。第三定时任务或外部回调在某个实例上被触发而这个实例上没有对应目标用户。最典型的是定时批量推送所有节点都在跑同一个定时任务每个节点推一遍结果消息重复或者你只在某个节点上执行定时任务但目标用户却连接在别的节点上消息丢失。6.2 方案一RabbitMQ STOMP插件做Broker Relay引入外部STOMP Broker是Spring官方推荐的集群方案也是最接近“改配置就能用”的路线。我用的是RabbitMQ的STOMP插件。先启用插件rabbitmq-plugins enable rabbitmq_stomp然后配置Broker RelayOverride public void configureMessageBroker(MessageBrokerRegistry registry) { registry.enableStompBrokerRelay(/topic, /queue) .setRelayHost(rabbitmq.internal) .setRelayPort(61613) .setSystemLogin(admin) .setSystemPasscode(admin) .setSystemHeartbeatSendInterval(10000); registry.setApplicationDestinationPrefixes(/app); registry.setUserDestinationPrefix(/user); }开启Broker Relay后Spring应用实例不再保存订阅关系而是把STOMP帧转发给RabbitMQ由RabbitMQ统一维护。这样节点A上的消息推给RabbitMQ后RabbitMQ知道目标用户连接的session属于节点B会通过系统连接把消息转发给节点B节点B再发给对应的WebSocket客户端。跨节点问题从架构上解决。这个方案要叮嘱三件事。第一Relay的端口是61613不是RabbitMQ默认的5672后者是AMQP协议端口别配错。第二RabbitMQ要用单独的系统账号做Relay不要直接暴露真实管理员密码。第三Broker Relay模式下应用节点本身对连接数的承载能力取决于系统连接池的配置高并发场景需要调大setTcpClient相关的线程数和心跳参数。6.3 方案二Redis Pub/Sub在应用层做广播不想引入RabbitMQ时另一个可行方案是用Redis Pub/Sub在应用层做消息广播。思想很简单所有应用节点订阅同一个Redis Channel当某个节点需要推送消息时先发布到Redis所有节点收到后判断目标用户是否连接在本地实例如果是再通过本地的SimpMessagingTemplate发送给WebSocket客户端。Configuration public class RedisWsBroadcastConfig { Bean public RedisMessageListenerContainer redisMessageListenerContainer( RedisConnectionFactory connectionFactory, RedisWsMessageListener listener) { RedisMessageListenerContainer container new RedisMessageListenerContainer(); container.setConnectionFactory(connectionFactory); container.addMessageListener(listener, new PatternTopic(ws:notify)); return container; } }监听器Component public class RedisWsMessageListener implements MessageListener { private final SimpMessagingTemplate messagingTemplate; private final ObjectMapper objectMapper; // 省略构造方法 Override public void onMessage(Message message, byte[] pattern) { try { WsPushMessage pushMessage objectMapper.readValue(message.getBody(), WsPushMessage.class); messagingTemplate.convertAndSendToUser(pushMessage.getUserId(), /queue/notify, pushMessage.getPayload()); } catch (IOException e) { log.error(解析Redis推送消息失败, e); } } }发布端redisTemplate.convertAndSend(ws:notify, objectMapper.writeValueAsString(pushMessage));这个方案的好处是部署简单只要Redis集群本身是高可用的节点之间的同步就能做到基本实时。缺点也很明显Redis Pub/Sub没有持久化消息发出去如果所有节点都没收到消息就丢了。可以用Redis Streams或Kafka替代Pub/Sub来做持久化但那样逻辑会重很多适合对可靠性要求更高的场景。6.4 粘性会话与集群里的user destination有同学会问我的Nginx配了ip_hash把同一用户的连接粘到同一节点是不是就不用管集群了答案是不行。粘性会话能减少节点漂移但解决不了两个问题一是节点宕机后用户重连会被转发到其他节点二是服务端内部触发推送时消息可能从任意节点发起发起节点未必是用户所在节点。如果坚持用SimpleBroker必须接受会话本地化的现实。在消息广播时不要直接使用convertAndSendToUser而是走Redis广播层消息里带上目标userId每个节点收到广播后先检查本地会话里是否存在该用户存在才调用本地模板推送。这套逻辑public boolean hasLocalSession(String userId) { // 从WebSocketSessionRegistry中判断当前节点是否存在该用户的活跃会话 }这里会引出一个新需求维护“用户-会话”的本地注册表。你可以做一个SessionRegistry在WebSocket握手成功和断开时更新。如果不想自己维护注册表可以用Spring的DefaultSimpUserRegistry它会统计当前节点连接了哪些用户。监听SessionConnectEvent和SessionDisconnectEvent可以拿到最新的用户会话状态。再从集群视角看一眼没有外部Broker时/user队列本身就是本地概念。消息的主体路由逻辑放在应用层广播里各节点自行判断是否消费这其实是一种去中心化广播模式简单可靠中小规模集群够用。7. 可靠性补充心跳、断线重连、消息幂等7.1 心跳参数怎么设置WebSocket连接有个现实问题Nginx、云负载均衡等中间层设备默认会清理空闲连接。连接上没有数据流动中间设备认为是死连接直接给你掐断。解决手段就是心跳。STOMP协议自带心跳机制客户端和服务端各自声明自己能接受的心跳间隔取两者较大值作为实际心跳周期。服务端配置registry.enableSimpleBroker(/topic, /queue) .setHeartbeatValue(new long[]{10000, 10000});客户端stompjs配置const client new StompJs.Client({ brokerURL: wss://yourdomain.com/ws, reconnectDelay: 5000, heartbeatIncoming: 10000, heartbeatOutgoing: 10000, });心跳间隔要小于负载均衡的空闲超时。比如Nginx默认proxy_read_timeout 60s你的心跳间隔设置成75秒必死。一般10秒比较稳妥也不会给服务端带来太大压力。7.2 断线重连与Token过期前端断线后WebSocket的onclose事件触发客户端要主动重连。stompjs提供了reconnectDelay但要注意重连时如果还是用原来的Token万一Token已经过期重连就会一直失败。合理的流程是前端收到WebSocket连接关闭事件后先调用HTTP刷新Token接口拿到新Token后再发起重连。如果刷新Token也失败了就跳回登录页。Token过期这事在长连接场景下比HTTP场景更值得关注因为连接会存活很长时间而JWT的有效期通常只有几十分钟到几个小时。7.3 消息幂等与补偿推送WebSocket推送不是天然可靠的网络闪断、服务端宕机、客户端崩溃任何一环出问题消息就丢了。做“可靠推送”核心思路是把消息本身当作业务数据落库然后定时补偿。我给每位用户维护一个notify_sequence游标。服务端推送时给每条消息分配唯一的msgId客户端收到后缓冲并展示同时上报确认。确认报文走/app/ack目的地MessageMapping(/ack) public void ack(Payload AckMessage ackMessage) { notifyMessageService.markAcknowledged(ackMessage.getMsgId()); }补偿任务定期扫描超过N秒还没确认的消息重新推送。这里要注意必须保证客户端对重复消息做幂等处理。最简单的做法是客户端维护一个SetString receivedMsgIds重复消息直接丢弃。我还会在推送前先写数据库再发WebSocket。这样即使推送全挂前端下次进入页面时还能通过HTTP接口拉取未读消息。WebSocket适合做“实时触达”不能当成“存储系统”。7.4 一张排错清单最后放一张我自己排查问题时的检查清单每次线上反馈“推送有问题”我就按这个顺序查先看握手日志Token校验是否通过是不是有大量401握手失败。再看客户端订阅是否成功/user/queue/notify是否真的订阅上了。查看消息是哪个节点发出的目标用户在哪个节点本地会话注册表里有没有这个用户。检查心跳是否正常有没有被中间层切断连接导致客户端实际离线。最后看补偿任务有没有把这些消息补发。如果用了Redis广播检查Redis Channel订阅是否正常各节点是否都收到了同一份广播。这套顺序用下来90%的推送问题都能在15分钟内定位到根因。最后如果让我只留一条经验别把“长连接”当成一定可靠服务端真正要守住的是消息的落库和幂等。WebSocket只是那根“更快的触手”补偿机制和兜底查询才是推送系统最后的安全网。