即时通讯系统设计核心：连接管理、消息可靠与状态一致性

发布时间：2026/10/24 1:36:26

1. 这不是聊天软件，而是现代数字协作的底层血管

“即时通讯系统是什么？”——这个问题看似简单，但如果你真去问十个不同岗位的人，大概率会得到十个不同答案：产品经理可能说它是用户留存的钩子，运维工程师会脱口而出“长连接+消息队列+状态同步”，前端开发者第一反应是WebSocket和心跳保活，而普通用户只会点开微信、钉钉或飞书，顺手发个“在吗？”。这恰恰说明，即时通讯系统（IM）早已不是某个App的功能模块，而是像水电一样嵌入所有数字服务的基础设施。它不喧哗，却支撑着在线教育里的实时白板协作、远程医疗中的医患图文问诊、智能客服背后的意图识别与多轮对话调度、甚至工业物联网中设备告警的毫秒级推送。我做过三个不同量级的IM相关项目：一个日活20万的内部协同工具，一个接入500+第三方SaaS系统的开放消息平台，还有一个为某高校实验室定制的低带宽学术协作系统。实测下来，真正决定IM系统成败的，从来不是UI有多炫，而是当3000人同时在同一个群聊里刷屏时，最后一条消息能否在800ms内触达每个终端；是当用户手机切到后台又切回前台的0.3秒间隙里，离线消息能否无缝续上而不丢序；是当网络从4G突然跌到弱WiFi再断连2秒后重连，已发送但未确认的消息会不会被重复投递。这些细节背后，是一整套关于连接管理、消息生命周期、状态一致性与容错恢复的精密设计逻辑。本文不讲概念定义，也不堆砌协议名词，只拆解一个合格的即时通讯系统在真实场景中必须解决的硬核问题、技术选型背后的取舍权衡，以及那些只有踩过坑才懂的实操细节。适合正在评估自建IM方案的技术负责人、需要深度集成消息能力的中台开发，以及想搞懂“为什么我的聊天功能总卡顿”的全栈工程师。

2. 系统设计的本质：在不可靠网络上构建可靠通信

2.1 核心矛盾：网络的天然不可靠性 vs 业务的强实时性要求

所有IM系统设计的起点，都是直面一个无法回避的物理现实：互联网本身是不可靠的。TCP能保证传输不丢包，但无法保证不延迟；UDP快，却要自己处理丢包重传；而移动网络更残酷——信号波动、基站切换、省电策略强制断连，让一次“稳定连接”成了奢望。某次我们为某在线教育平台做IM优化，压测时发现：当500名学生同时加入一节直播课，客户端平均建立长连接耗时从200ms飙升至1.8秒，其中73%的失败源于运营商NAT超时。这直接导致前3秒内大量学生收不到老师发布的课件链接。问题根源不在代码，而在设计之初没把“连接建立”当作一个可降级的异步过程来对待。真正的IM系统设计，本质是在承认网络不可靠的前提下，通过分层策略构建“感知上的可靠”。它分为三层：

连接层：解决“怎么连上”的问题。不是简单地open WebSocket，而是要设计连接池、自动重连退避算法（如指数退避）、连接预热机制（在用户打开App时就提前建立备用连接），甚至在极端弱网下启用HTTP短轮询兜底。我们给某金融类App做的方案中，将首次连接成功率从89%提升到99.2%，关键就是把重连间隔从固定2秒改为“1s→2s→4s→8s→16s”的动态序列，并在第3次失败后自动切换到HTTPS长轮询通道。
消息层：解决“消息怎么不丢、不错、不乱”的问题。这里最常被误解的是“已读回执”——很多人以为它只是UI上一个小勾，实际上它触发了一整套状态同步流程：发送端标记“已送达服务器”→服务器写入离线库并推送给接收方→接收方本地存储并上报“已读”→服务器更新全局状态并反向通知发送方。任何一个环节中断，都会导致状态不一致。我们曾遇到一个典型故障：某次数据库主从延迟突增到12秒，导致“已读”状态回写失败，结果用户A看到自己发的消息显示“已读”，而用户B实际根本没看到。最终解决方案不是加缓存，而是在状态写入链路中增加本地持久化+异步补偿任务，确保即使服务端短暂异常，终端也能在下次联网时补全状态。
状态层：解决“用户现在在线吗？在哪个设备？”的问题。这看似简单，实则最难。因为“在线”不是二元状态，而是连续谱系：前台活跃、后台挂起、网络断开、设备休眠……我们给某社交App做的状态系统，最终采用三重信号融合：WebSocket心跳（毫秒级）、APP前台/后台事件（秒级）、设备网络状态广播（亚秒级）。当三者出现冲突时，以“最近一次可信信号”为准，并设置15秒的模糊窗口期——比如心跳超时后不立即标为离线，而是进入“疑似离线”态，等待其他信号确认。这个设计让误判率从12%降到0.7%，代价是增加了状态同步的复杂度，但换来的是用户真实的体验流畅感。

提示：不要迷信“全链路追踪”这类高大上方案。在IM场景中，最有效的监控往往是最朴素的——在每条消息的发送、到达、展示、已读四个关键节点埋点，并计算各环节P95耗时。我们发现，80%的“消息延迟”投诉，其实源于“到达”到“展示”的300ms卡顿，根源是前端消息列表渲染性能不足，而非后端推送慢。

2.2 架构选型：单体、微服务还是Serverless？没有银弹，只有权衡

市面上常见三种IM架构，没有绝对优劣，只有场景适配：

单体架构：所有逻辑（连接管理、消息路由、存储、推送）打包在一个服务里。优点是开发调试极快，本地启动5分钟就能跑通全流程；缺点是水平扩展困难，一旦连接数破10万，单机CPU和内存必然成为瓶颈。我们给某初创公司做的MVP版本，就用Python+Tornado+Redis快速搭出原型，3天上线支持5000并发，但当用户量涨到8万时，单机Redis内存暴涨至95%，GC停顿导致消息积压。此时重构已不可避免。
微服务架构：将连接网关、消息总线、状态服务、存储服务、推送服务拆成独立进程。这是目前主流选择，但代价巨大。某次我们帮某电商公司重构其客服IM系统，拆出7个微服务，光是服务间鉴权和链路追踪的配置就花了2周。更麻烦的是，当用户在APP和小程序同时登录时，如何保证两个终端收到的消息顺序一致？这需要在消息总线上引入全局单调递增ID（如Snowflake ID），并在消费端做严格保序。我们最终采用Kafka分区+消费者组+本地排序缓冲区的组合方案，但测试发现，当某个分区消费延迟时，整个用户的消息流都会被阻塞。后来改用RabbitMQ的优先级队列+时间戳排序，在消费端用环形缓冲区暂存乱序消息，等“窗口期”内所有消息到齐后再按序分发，P99延迟从2.3秒降到380ms。
Serverless架构：用云函数处理连接事件、用托管消息队列做中转、用对象存储存离线消息。优势是极致弹性，零运维成本；劣势是冷启动延迟（通常300-800ms）和调用链路过长。我们曾尝试用AWS Lambda+API Gateway搭建轻量IM，结果发现：当用户发送一条消息，需经历“API网关→Lambda1（鉴权）→SQS→Lambda2（路由）→DynamoDB→Lambda3（推送）”共6跳，平均延迟达1.2秒，完全无法满足IM的实时性要求。最终只将离线消息存储和推送通知这两个非实时环节迁移到Serverless，核心连接和消息路由仍保留在常驻容器中。

注意：很多团队过早陷入“架构之争”，却忽略了最基础的容量规划。我们坚持一个铁律：在设计任何IM系统前，必须先明确三个数字——峰值连接数、消息TPS（每秒事务数）、单用户日均消息量。这三个数决定了你该用Redis Cluster还是TiKV，该选Kafka还是Pulsar，甚至该不该自研。例如，若峰值连接数<5万且消息TPS<1000，用单体+Redis足够；若连接数超50万且要求跨机房容灾，则必须上微服务+分布式消息中间件。

3. 核心技术点拆解：从连接建立到消息投递的完整链路

3.1 长连接管理：不只是WebSocket，更是状态生命周期的精细控制

WebSocket是IM的标配，但仅开启ws://连接远远不够。真正的挑战在于如何管理数百万并发连接的状态。我们采用“连接-会话-用户”三级抽象：

连接（Connection）：指一个TCP连接，对应一个WebSocket实例。它是最底层的资源，受操作系统文件描述符限制。我们通过调整Linux内核参数（fs.file-max、net.core.somaxconn）和应用层连接池（如Netty的ChannelGroup）来管理。关键技巧是：为每个连接分配唯一connectionId，并在连接建立时立即写入Redis的Set集合（key为"online:connections"），这样就能实时统计在线连接数。
会话（Session）：指一个用户在某台设备上的逻辑会话。一个用户可能有多个会话（手机、iPad、网页端）。我们在Redis中用Hash结构存储会话信息：key为"session:{userId}:{deviceId}"，field包括lastActiveTime（最后活跃时间）、ip（IP地址）、clientType（客户端类型）。每次心跳时更新lastActiveTime，并用Redis的EXPIRE命令设置30分钟过期——这样既避免手动清理，又能在用户长时间无操作后自动下线。
用户（User）：指业务层面的用户实体。我们维护一个"online:users"的Sorted Set，score为lastActiveTime的时间戳，member为userId。这样就能用ZRANGEBYSCORE快速查出“最近5分钟活跃的用户列表”，用于在线状态展示。

这套设计解决了几个关键问题：
第一，连接复用。当用户在手机端退出APP再重新打开，新连接会复用旧会话ID，避免重复推送离线消息；
第二，多端互踢。当用户在新设备登录时，系统遍历该用户的全部会话，向其他设备发送“被踢下线”通知，并主动关闭对应连接；
第三，精准推送。消息路由时，先查"online:users"判断用户是否在线，若在线则查"session:{userId}:*"获取所有活跃会话，再逐个推送——而不是盲目群发。

实操心得：别用Redis的Pub/Sub做消息广播！我们早期曾用它实现群聊消息分发，结果发现当群成员超200人时，单条消息会触发200次Redis Pub/Sub操作，CPU使用率飙升。后来改用“消息中心+拉取模式”：群消息统一写入Kafka Topic，每个客户端监听自己所属的Topic分区，再按需拉取。吞吐量提升4倍，延迟降低60%。

3.2 消息可靠性保障：ACK机制与本地存储的黄金组合

IM最怕的不是慢，而是丢消息。我们的方案是“服务端ACK + 客户端本地存储”双保险：

服务端ACK：当客户端发送消息，服务端成功写入消息队列后，立即返回{"msgId":"xxx","status":"success"}。客户端收到此响应，才将该消息从本地“待发送队列”中移除，并标记为“已发送”。如果网络中断导致ACK丢失，客户端会在重连后重新发送该消息（携带相同msgId），服务端通过msgId去重，避免重复入库。
客户端本地存储：所有消息（发送中、已发送、已接收）都持久化到本地数据库（Android用Room，iOS用CoreData，Web用IndexedDB）。关键设计是：
- 发送消息时，先写入本地表，状态为“sending”；
- 收到服务端ACK后，更新状态为“sent”；
- 收到对方“已读”回执后，更新状态为“read”；
- 若发送失败，状态保持“sending”，并在后台定时重试。

这套机制让我们在某次线上事故中避免了重大损失：某天凌晨Redis集群因磁盘满导致写入失败，持续12分钟。由于客户端本地存储完备，用户发送的所有消息都保留在“sending”状态，待服务恢复后自动重试，全程无感知。而竞品因依赖纯服务端存储，导致那12分钟内所有消息永久丢失。

常见误区：很多人认为“消息已送达服务器”就等于“用户已看到”。实际上，从服务端到客户端还有至少两道关卡：一是推送服务（APNs/FCM）的送达率通常只有92%-95%，二是客户端App可能被系统杀死，导致推送无法唤醒进程。因此，我们强制要求所有重要消息（如支付确认、密码修改）必须走“服务端推送+客户端轮询”双通道，并在客户端启动时主动拉取“未读消息”。

3.3 群聊与消息同步：顺序一致性比性能更重要

群聊是IM中最复杂的场景。难点不在“发消息”，而在“所有人看到的顺序必须一致”。我们曾为某政务系统做群聊改造，发现当管理员在群内发布一条紧急通知，不同用户看到的时间差最大达47秒——根源是消息路由路径不一致：有的走A节点，有的走B节点，而各节点间的时钟偏差达200ms，导致消息ID生成顺序混乱。

解决方案是引入全局有序消息ID。我们放弃用时间戳做ID（易受时钟漂移影响），改用“逻辑时钟+节点ID”组合：

每个消息网关节点启动时，从ZooKeeper获取唯一workerId（如001, 002）；
每次生成消息ID时，取当前毫秒时间戳（41位）+ workerId（10位）+ 序列号（12位）；
所有群消息必须经由同一台网关节点处理（按群ID哈希路由），确保同一群内的消息ID严格递增。

这样，消费端只需按ID升序处理，就能100%保证顺序。但代价是牺牲了部分负载均衡——我们通过动态权重调整，让高负载节点自动降低路由权重，避免单点过载。

关键细节：群聊消息的“已读回执”不能按人统计，而要按“消息批次”统计。比如100人进群，第一条消息发出后，系统不记录“张三已读”“李四已读”，而是记录“群ID:123, msgId:abc, readCount:100”。这样当第101人进群时，只需查询该批次的readCount，就能立刻知道有多少人已读，无需遍历100条记录。我们用Redis的HyperLogLog统计去重人数，用Sorted Set存消息批次，将“查询已读率”从O(n)降到O(1)。

4. 实操落地：从零搭建一个可商用的IM基础框架

4.1 技术栈选型与环境准备：务实比时髦更重要

我们不追逐最新技术，只选经过大规模验证的组合。以下是当前主力项目的技术栈：

组件	选型	选型理由
连接网关	Netty 4.1 + Spring Boot	Netty对高并发连接管理成熟稳定，Spring Boot便于集成监控和配置管理
消息总线	Apache Pulsar 2.10	相比Kafka，Pulsar原生支持多租户、分层存储（热数据存BookKeeper，冷数据自动转S3），且Topic数量无上限，适合IM海量群聊场景
状态存储	Redis Cluster 7.0	高性能读写，Cluster模式支持水平扩展；用GEO功能实现“附近的人”等LBS功能
离线消息	TiKV 6.5	分布式KV存储，强一致性，支持海量消息持久化；相比MySQL，写入QPS高3倍，且无DDL锁表风险
推送服务	自研HTTP/2网关 + APNs/FCM	避免第三方SDK的兼容性问题；HTTP/2多路复用降低连接数，APNs/FCM官方通道保障送达率

环境准备的关键步骤：

内核调优：在Linux服务器上执行sysctl -w net.core.somaxconn=65535，sysctl -w fs.file-max=2097152，并修改/etc/security/limits.conf增加* soft nofile 1048576；
JVM参数：Netty网关用G1垃圾收集器，堆内存设为物理内存的75%，并添加-XX:+UseStringDeduplication减少字符串重复内存占用；
Pulsar部署：至少3节点BookKeeper集群（保证WAL日志高可用），2节点Broker（负载均衡），1节点ZooKeeper（元数据管理）；
Redis Cluster：6节点（3主3从），每个主节点分配16384个slot，用redis-cli --cluster create一键初始化。

注意：千万别在生产环境用Docker Compose部署Pulsar！我们吃过亏——某次升级Pulsar版本，Compose重启时BookKeeper节点顺序错乱，导致WAL日志无法恢复，丢了2小时消息。现在所有核心组件都用Kubernetes Helm Chart部署，通过StatefulSet保证有状态服务的启动顺序。

4.2 核心代码实现：消息发送与接收的最小可行闭环

以下是一个精简但可运行的Netty消息网关核心逻辑（Java）：

// 消息处理器 @ChannelHandler.Sharable public class IMMessageHandler extends SimpleChannelInboundHandler<IMMessage> { // 消息总线生产者（Pulsar） private final Producer<byte[]> pulsarProducer; // 用户会话映射（内存缓存，与Redis同步） private final Map<String, Channel> userChannelMap = new ConcurrentHashMap<>(); public IMMessageHandler(Producer<byte[]> producer) { this.pulsarProducer = producer; } @Override protected void channelRead0(ChannelHandlerContext ctx, IMMessage msg) throws Exception { String userId = msg.getUserId(); String msgId = msg.getMsgId(); // 1. 存储用户会话（内存+Redis双写） userChannelMap.put(userId, ctx.channel()); redisTemplate.opsForHash().put("session:" + userId, "channelId", ctx.channel().id().asLongText()); redisTemplate.expire("session:" + userId, Duration.ofMinutes(30)); // 2. 消息路由逻辑 if ("GROUP".equals(msg.getType())) { // 群聊消息：发往Pulsar指定Topic String topic = "persistent://public/default/group-" + msg.getGroupId(); pulsarProducer.newMessage() .key(msgId) .value(JSON.toJSONString(msg).getBytes()) .sendAsync(); // 异步发送，避免阻塞IO线程 // 3. 立即返回ACK给发送方 ctx.writeAndFlush(new ACKMessage(msgId, "success")); } else if ("PRIVATE".equals(msg.getType())) { // 私聊消息：查接收方会话，直连推送 Channel receiverChannel = userChannelMap.get(msg.getToUserId()); if (receiverChannel != null && receiverChannel.isActive()) { receiverChannel.writeAndFlush(msg); ctx.writeAndFlush(new ACKMessage(msgId, "delivered")); } else { // 接收方离线，存离线消息 saveOfflineMessage(msg); ctx.writeAndFlush(new ACKMessage(msgId, "offline")); } } } }

这段代码实现了三个关键能力：

会话绑定：将用户ID与Netty Channel关联，为后续推送打基础；
异步解耦：群消息走Pulsar异步处理，避免阻塞Netty IO线程；
分级响应：私聊消息能直连推送则返回“delivered”，否则存离线并返回“offline”，让客户端知道后续要拉取。

实操技巧：Netty的ChannelHandler必须加@ChannelHandler.Sharable注解，否则每个Channel会创建独立实例，导致内存泄漏。我们曾因漏加此注解，上线3天后内存占用从2G涨到16G，GC频繁，最终OOM。

4.3 离线消息同步：让“断网再连”变得毫无感知

离线消息同步是用户体验的分水岭。我们的方案叫“三段式同步”：

第一阶段：连接建立时的快速同步
客户端连接成功后，立即发送{type:"sync_offline", lastMsgId:"xxx"}请求。服务端查询TiKV，返回lastMsgId之后的最多50条消息（避免单次响应过大）。客户端收到后，按ID升序插入消息列表顶部。
第二阶段：增量拉取
快速同步完成后，客户端发起长轮询/api/v1/messages?since=lastMsgId&limit=100。服务端用TiKV的Scan接口扫描msg:{userId}:{timestamp}范围，返回新增消息。此接口超时设为30秒，若无新消息则返回空数组，客户端立即发起下一轮。
第三阶段：兜底校验
每隔2小时，客户端主动请求/api/v1/messages/check?from=2h_ago&to=now，服务端对比本地消息计数与客户端上报的已读数，若差异>5条，则强制触发全量同步（限速100条/秒，避免冲击数据库）。

这套机制让离线消息同步的P95延迟稳定在1.2秒内。最关键的设计是：所有同步接口都要求客户端携带lastMsgId，服务端只返回此ID之后的消息，绝不返回历史全量。这避免了因客户端本地数据损坏导致的无限循环同步。

踩过的坑：某次我们用MySQL做离线消息存储，当用户离线7天后重连，单次查询要扫描数万行，耗时超15秒。换成TiKV后，同样场景耗时降至320ms——因为TiKV的LSM树结构对范围查询极度友好，且分布式架构可线性扩展。

5. 常见问题排查与避坑指南：来自真实战场的经验

5.1 连接闪断：90%的问题出在客户端保活策略

现象：用户反馈“消息经常收不到”，抓包发现WebSocket频繁断开重连。
排查思路：

先看客户端日志——是否在切后台时主动关闭了连接？
再看服务端日志——断连时是否有CLOSE_NORMAL（正常关闭）或CLOSE_ABNORMAL（异常关闭）？
最后看网络层——用tcpdump抓包，分析FIN/RST包来源。

我们定位到一个经典案例：某Android App在华为手机上连接闪断率高达40%。原因竟是华为EMUI的“智能省电”策略——当App进入后台，系统会强制回收其TCP连接。解决方案不是改服务端，而是客户端适配：

在onPause()时，不关闭WebSocket，而是调用websocket.close(1001, "going to background")发送标准关闭帧；
在onResume()时，检查连接状态，若已断开则立即重连；
同时在AndroidManifest.xml中添加<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>，引导用户关闭省电优化。

避坑清单：
iOS上，WebSocket在App进入后台5秒后会被系统挂起，必须依赖APNs推送唤醒；
Web端，Chrome浏览器对后台Tab的WebSocket心跳间隔会延长至30秒，需在心跳超时时主动重连；
所有客户端必须实现“心跳超时自动重连”，且重连间隔要指数退避，避免雪崩。

5.2 消息乱序：时间戳不是万能的，逻辑时钟才是

现象：群聊中，用户A发的消息显示在用户B发的消息之后，尽管A先发送。
根因分析：

客户端时间不同步（尤其低端安卓机，时钟漂移可达±5秒）；
服务端多节点时间不同步（NTP服务异常）；
消息路由路径不一致（A消息走Node1，B消息走Node2，Node1处理慢）。

终极解决方案：弃用时间戳，改用逻辑时钟。我们在Pulsar中为每个Topic配置deduplicationEnabled=true，并要求客户端发送消息时携带sequenceId（从0开始递增）。服务端收到后，用pulsarProducer.newMessage().sequenceId(seqId)写入，Pulsar Broker会自动按sequenceId排序。消费端用consumer.seek(MessageId.earliest)从头消费，就能严格保序。

实操验证：我们用JMeter模拟1000并发用户，每秒发送1000条消息，乱序率从12.7%降至0%。代价是客户端需维护sequenceId状态，但我们把它封装在SDK里，业务层无感知。

5.3 存储爆炸：消息体膨胀的隐形杀手

现象：TiKV集群磁盘空间每周增长30%，但业务消息量只增5%。
排查发现：客户端上传的图片消息，服务端未做压缩直接存储。一张3MB的PNG，经Base64编码后变成4MB文本，再存入TiKV，实际占用6MB（TiKV的Raft日志+副本）。

解决方案是“存储分层”：

热数据（7天内）：原始消息体存TiKV，但图片/视频等大文件，只存URL，文件本身存对象存储（如MinIO）；
温数据（7-90天）：消息体用Snappy压缩，压缩率约35%，再存TiKV；
冷数据（90天以上）：归档到HDFS，只保留索引。

我们还加了一道防线：在Netty网关入口，用HttpObjectAggregator限制单条消息最大1MB，超限则返回413 Payload Too Large，强制客户端分片上传。

关键经验：永远不要相信客户端传来的“Content-Length”。我们曾因未校验，导致恶意用户上传1GB文件，填满Pulsar BookKeeper磁盘，引发集群雪崩。现在所有入口都加了MaxContentLength拦截器。

5.4 推送失效：你以为的“已送达”，其实是“已发出”

现象：用户投诉“消息没收到”，但服务端日志显示“APNs推送成功”。
真相是：APNs返回的“成功”，仅代表苹果服务器已接收，不代表设备已收到。实际送达率受制于：

设备是否在线（Wi-Fi/蜂窝网络）；
设备是否开启了推送通知权限；
iOS系统是否在后台杀死了App进程。

我们的应对策略是“双通道确认”：

所有推送都带mutable-content=1，让iOS在收到推送时唤醒App Extension，执行JS脚本检查本地消息状态；
若发现推送对应的消息本地不存在，则立即调用fetchMessages(since=lastSyncTime)拉取；
同时，服务端维护一个“推送未确认队列”，每5分钟扫描一次，对超10分钟未确认的推送，触发短信/邮件备用通道。

这套方案将“用户实际看到消息”的成功率从89%提升到99.6%。

最后分享一个小技巧：在IM系统上线前，务必做“断网压力测试”。方法是：用Charles代理截断所有网络请求，让客户端处于完全离线状态，持续2小时，然后恢复网络。观察离线消息同步是否完整、顺序是否正确、本地存储是否溢出。我们每次大版本上线前都做此测试，已拦截3次重大数据丢失隐患。

我在实际搭建第四个IM系统时，把上述所有经验浓缩成一份《IM系统健康度检查清单》，包含27个必检项，从连接建立成功率、消息端到端P95延迟、离线消息同步准确率，到数据库慢查询率、推送到达率。这份清单现在已成为团队的标准交付物——不是因为它多完美，而是因为每一项背后，都对应着一次深夜的故障复盘和一次用户的投诉录音。IM系统没有惊天动地的创新，它的价值，就藏在用户每一次顺畅的对话、每一条不丢失的通知、每一个不掉线的会话里。