开发即时通讯软件时如何实现群公告的发布和提醒

做即时通讯软件这些年会发现，群聊功能看着简单，真正要做好的时候，里面的门道其实不少。就说群公告这个功能吧，好像就是发一段文字、加个置顶，实际做下来要考虑的细节远比表面上看起来多。这篇文章我想从技术实现的角度，聊聊群公告发布和提醒机制到底是怎么做出来的，中间会遇到哪些问题，又该怎么解决。

对了，这里我会结合声网的一些技术方案来讲，毕竟他们在实时互动领域积累了不少经验，里面的思路大家可以参考参考。

一、先搞清楚：群公告到底是个什么东西

从用户的角度看，群公告就是管理员发的一段重要信息，会显示在群聊界面的显眼位置，用户打开群就能看到。从技术的角度看，它其实是一个带有特殊属性的消息，只是这个消息被赋予了更高的优先级和更长的生命周期。

你可能会想，那直接发一条普通消息置顶不就行了吗？事情没那么简单。普通消息会被后来的消息顶走，会被用户手动滑走，还可能因为消息撤回而消失。但群公告需要的是——无论群里有多少消息，它都要稳稳地待在那里；用户不管什么时候进群，都能第一眼看到；而且只有有权限的人才能修改或删除。

所以群公告本质上是一个「特殊消息」，它和普通消息的区别大概是这样的：

搞明白这些区别，后面的技术方案就好设计了。

二、发布机制的技术实现

1. 权限控制：谁有资格发公告

不是所有人都能发公告的，这个得先在产品层面定清楚。一般来讲，群主和管理员肯定有权限，普通的群成员可能需要设置成「仅管理员可发布」或者「所有人可发布」。这个权限判断要放在服务端，不能信任客户端的任何请求。

服务端在收到发布公告的请求时，首先要做的事情就是校验这个用户的角色。怎么做呢？通常群组信息里会有一个成员列表，每个成员带有一个角色字段：owner表示群主，admin表示管理员，member表示普通成员。发布公告的接口应该先查一下这个群的基本信息，然后判断当前用户是否在权限列表里。

这里有个细节要注意——权限变更的实时性。比如某个人本来是管理员，后来被降级成普通成员了，这时候他如果还在发公告的界面快速点了一下发布，服务端必须能准确判断出他已经没有权限了。所以权限数据最好是从可靠的存储里实时读取，而不是缓存在某个地方等过期。

2. 内容处理：公告内容要存些什么

一条群公告存进数据库的时候，要存的东西可比普通消息多。基础的当然就是公告内容、发布时间、发布者这些。但为了让公告更实用，通常还会支持一些富文本格式，比如加粗、换行、链接，甚至附件。

那存储结构大概是这样的：公告ID是唯一标识，用来关联后续的已读状态等各种操作；群ID用来确定这条公告属于哪个群；发布者ID和发布者昵称要存，这样显示的时候能看到是谁发的；正文内容可以直接存文本，如果有富文本格式可能还需要存一下格式信息；发布时间戳用来排序和展示；另外最好再加一个版本号，每次修改公告的时候版本号递增，这样客户端可以用版本号来判断是否需要刷新。

声网在他们的即时通讯解决方案里，对消息体的设计就挺值得参考的。他们把消息分成了基础字段和扩展字段，基础字段所有消息类型都一样，扩展字段根据类型不同而变化。群公告作为一种特殊消息类型，就是在扩展字段里定义了自己的结构。这样做的好处是后续要加新功能或者改字段，不会影响到其他消息类型的处理逻辑。

3. 发布流程：消息是怎么发出去的

完整的发布流程大概是这样的：用户编辑好公告内容，点发布按钮，客户端把内容发送到服务端。服务端收到请求后，先做权限验证，再做内容安全检查（比如过滤敏感词），都没问题了就写入数据库。写入成功后，需要做两件事——一是把这个公告的变更同步给所有群成员，二是更新这个群的最新公告索引。

这里有个点值得展开说说，就是公告的同步策略。普通消息是实时推送的，但公告因为重要性更高，同步策略要更激进一些。最直接的做法是，服务端在公告发布成功后，立即向这个群的所有在线成员发一个通知，告诉他们「有新的群公告」。收到这个通知后，客户端不论当前在聊什么界面，都应该跳转到公告展示的地方，或者至少在界面上显示一个醒目的提示。

对于离线成员怎么办？等他们上线的时候，服务端要把未读的公告主动推过去。这个可以通过离线消息的机制来实现——公告发布的时候，不仅发给在线的人，还要写入离线消息存储。每个群成员的未读公告列表要单独维护，上线的时候一次性拉取。

三、提醒机制的技术实现

1. 为什么需要单独的提醒机制

你可能会问，既然公告发布的时候已经通知所有人了，那还要什么额外的提醒机制？这里有个用户体验的问题。

很多用户可能当时在线，但正在忙别的事，或者手机放在一边没看。等他看到通知点进去，公告可能已经被新的聊天顶到下面去了。或者更常见的情况——用户其实看了通知，但手一滑就过去了，根本没仔细读公告内容。

所以提醒机制的作用就是「确保用户注意到这条公告」。它和普通的推送通知不一样，普通消息推送是可以被忽略的，但公告提醒要做到用户必须做出某种操作才能让它消失。

2. 强提醒和弱提醒的设计

一般来说，群公告的提醒会分成两种级别：强提醒和弱提醒。

强提醒是指用户必须点击才能关闭的提示，弹窗形式，会打断用户的当前操作。这种一般用在非常重要的公告上，比如「今晚八点开会」「活动推迟到明天」这种。实现方式是在客户端本地维护一个未读公告列表，用户每次进群或者收到公告变更通知的时候，检查这个列表有没有强提醒的公告，有的话就弹窗。弹窗关闭后，这条公告的状态要从强提醒列表里移除。

弱提醒就是不弹窗，只在界面上显示一个小红点或者「有新公告」的提示。用户点进去能看到公告内容，不点也没关系，下次进群还是能看到。这种适合不太紧急的公告，比如「群规更新」「本周活动预告」之类的。弱提醒的实现更简单，服务端推送一个通知，客户端收到后在UI上显示标记就行。

那什么时候用强提醒，什么时候用弱提醒？通常是由发布者决定的，发布公告的时候有个开关，「是否开启强提醒」。或者有的产品会固定规则，比如群主发布的是强提醒，普通管理员发布的是弱提醒。这个可以根据产品需求灵活配置。

3. 推送通道的选择

公告提醒的推送通道和普通消息差不多，但因为重要性更高，在通道选择上可以更激进一点。

对于在线的用户，直接通过长连接推送就行，这个延迟最低，效果最好。对于离线用户，要走离线推送通道。这里有个问题——如果群里有两百个人，每个人都离线，那服务端要向两百个设备发离线推送吗？这样做推送量太大了，服务器压力也大，用户那边也可能被频繁的推送骚扰。

比较合理的做法是设置一个推送合并机制。比如五分钟内发布的公告，合并成一条推送，告诉用户「有X条群公告待查看」。或者更智能一点，只推送最新的那一条，因为旧的公告等用户上线后再看也不迟。

声网的推送策略我记得是这样的——他们对不同级别的消息有不同的推送优先级，公告属于高优先级，会优先走长连接，长连接断了才走离线推送。而且他们支持按设备状态动态调整推送策略，比如这台设备已经很久没上线了，就先不推，等它真正上线的时候再通过同步机制把数据带过去。这样既保证了消息的到达率，又避免了无效的推送资源消耗。

四、已读状态的管理

群公告有个很现实的需求——群主或管理员想知道公告被多少人看了。这个需求看起来简单，做起来有不少坑。

首先，已读状态是按公告来记录的。每条公告有自己独立的已读列表，记录哪些用户看过这条公告。这个列表存在哪呢？如果群里人不多，比如几十个人，存在公告的记录里没问题。但如果群很大，几百上千人，这个列表就会非常大，查询和更新的性能都会成问题。

更好的做法是单独建一张已读状态表，字段包括公告ID、用户ID、已读时间。主键是公告ID加用户ID的组合，这样查询某个公告的已读情况只要查这个公告ID对应的记录，查询某个用户看过哪些公告就查这个用户ID对应的记录。

然后是已读的触发时机。什么时候标记已读？最简单的是用户点开公告详情就标记已读。但用户体验上可能不太好——用户可能不小心点进去了，不想看也要标记成已读？所以有的产品会加个二次确认，「标记为已读？」。也有的产品是用户看满几秒钟才自动标记已读，这个要看产品怎么取舍。

还有一个问题是已读状态的同步。用户A在手机上看了一眼，标记已读。但用户A同时还登录着电脑版和网页版，这两个客户端怎么同步已读状态？服务端在收到某个客户端的已读请求后，要向这个用户的所有在线设备发一个已读通知，让它们更新本地的已读状态。

五、数据同步与一致性

做过即时通讯的都知道，多端数据同步是个麻烦事。群公告虽然不像聊天消息那样频繁，但同步的要求反而更高——因为公告是所有人都必须看到的，不能出现有人看到的是旧版本，有人看到的是新版本的情况。

先说方案一：版本号机制。每条公告有个自增的版本号，客户端在请求公告列表的时候带上自己本地的最大版本号。服务端如果发现客户端的版本号落后了，就把新版本的公告列表返回给它。这个方案简单有效，但有个小问题——如果公告更新很频繁，每次请求都可能返回大量数据。

方案二：增量同步。服务端维护每个用户对每个群的公告同步点，记录他同步到了哪个版本。每次请求的时候，只返回从那个版本之后的增量变更。这个方案更省带宽，但服务端要维护的同步状态也更多。

实际落地的时候，很多人会用方案一的变体——公告列表和公告详情分开同步。公告列表很小，每次请求无妨；公告详情比较大，但变更不频繁，用户点进去再看详情也行。

六、常见问题与解决方案

做群公告功能的过程中，会遇到一些典型问题，这里列出来供参考。

第一个问题是公告发布后显示有延迟。表现是用户A发布了公告，但用户B过了几秒才看到。这个问题通常出在数据同步的环节。服务端写库成功后，同步消息发到消息队列，再分发给各个接入节点，这个链路一长，延迟就上去了。解决方案是优化同步链路的层级，尽量减少中间环节，或者在写库之前先把同步消息发出去——当然这会增加数据不一致的风险，要权衡。

第二个问题是高并发下的性能问题。如果一个几千人的大群发布公告，瞬间要处理几千条推送请求，服务器压力会很大。解决方案是做请求削峰，把推送任务放到消息队列里慢慢处理，同时告诉客户端「正在同步中，请稍候」。对于特别大的群，还可以考虑只推送在线用户，离线用户上线再拉取。

第三个问题是已读状态不一致。两个人都觉得自己已经看过公告了，但服务端显示其中一个没看过。这种情况一般是客户端本地的已读状态没及时同步到服务端。解决思路是在关键操作节点强制同步已读状态，比如切到后台的时候、离开群聊的时候、应用退出的时候。

七、写在最后

群公告这个功能，看起来是即时通讯里的一个小模块，真要做透了要考虑的东西一点都不少。从权限控制到内容存储，从推送策略到已读同步，每个环节都有细节要打磨。

如果你正在开发自己的即时通讯产品，建议先把基础的用户体验做好——能发、能看、能提醒，这三点先保证，再慢慢优化细节。像声网这种在实时通讯领域深耕多年的团队，他们的技术方案里有很多现成的坑和解决方案可以参考，省得自己再摸索一遍。

功能上线后，多收集用户反馈，看看大家在使用过程中遇到什么问题，再针对性地迭代。毕竟做产品不是一蹴而就的事，持续改进才能把体验做好。