前些天所在部门出去团建，于是公司行政和 HR 拉了一个微信群，发布一些跟团和集合信息。
当我正在查看途径路线和团建行程时，忽然一条带着喜意的消息扑面而来，消息上赫然带着八个大字：恭喜发财，大吉大利。
抢红包！！原来是公司领导在群里发了个红包，于是引得群员哄抢，气氛其乐融融。
毕竟，团不团建无所谓，不上班就很快乐；抢多抢少无所谓，有钱进就很开心。
打工人果然是最容易满足的生物！
我看着群里嬉戏打闹的聊天，心中陷入了沉思：微信这个集齐了陌生人聊天、文件分享和抢红包功能的群聊设计确实有点意思，如果在面试或者工作中让我们设计一个群聊系统，需要从哪些方面来考虑呢？
面试官：微信作为 10 亿用户级别的全民 App，有用过吧？
我：（内心 OS，说没用过你也不会相信啊~）当然，亲爱的面试官，我经常使用微信来接收工作消息和文件，并且经常在上面处理工作内容。
面试官：（内心 OS：这小伙子工作意识很强嘛，加分！）OK，微信的群聊功能是微信里面核心的一个能力，它可以将数百个好友或陌生人放进一个群空间，如果让你设计一个用户量为 10 亿用户的群聊系统，你会怎么设计呢？
我：首先群聊功能是社交应用的核心能力之一，它允许用户创建自己的社交圈子，与家人、朋友或共同兴趣爱好者进行友好地交流。
以下是群聊系统常见的几个功能：
图片
除了功能需要，当我们面对 10 亿微信用户每天都可能使用建群功能的情景时，还需要处理大规模的用户并发。
这就引出了系统的非功能需求，包括：
面试官：嗯，不错，那你可以简要概述一下这几个常用的功能吗？
我：好的，我们首先做系统的概要设计，这里涉及到群聊系统的核心组件和基本业务的概要说明。
群聊系统中，会涉及到如下核心组件和协议。
图片
在业务概要说明里，我们关注用户的交互方式和数据存储......
面试官：稍等一下，群聊系统的好友建群功能比较简单，拉好友列表存数据就可以了！你用过面对面建群吧，可以简要说一下如何设计面对面建群功能吗？
我：（内心 OS，还好之前在吃饭时用过面对面建群结账，不然就G了），好的，群聊系统除了拉好友建群外，还支持面对面建群的能力。
用户发起面对面建群后，系统支持输入一个 4 位数的随机码，周围的用户输入同一个随机码便可加入同一个群聊，面对面建群功能通常涉及数据表设计和核心业务交互流程如下。
图片
用户 A 在手机端应用中发起面对面建群，并输入一个随机码，校验通过后，等待周围（50 米之内）的用户加入。此时，系统将用户信息以 HashMap 的方式存入缓存中，并设置过期时间为 3min。
{随机码，用户列表[用户A(ID、名称、头像)]}
用户 B 在另一个手机端发起面对面建群，输入指定的随机码，如果该用户周围有这样的随机码，则进入同一个群聊等待页面，并可以看到其它群员的头像和昵称信息。
此时，系统除了根据随机码获取所有用户信息，也会实时更新缓存里的用户信息。
当第一个用户点击进入该群时，就可以加入群聊，系统将生成的随机码保存在 RandomCode 表中，并关联到新创建的群 ID，更新群成员的个数。
然后，系统将用户信息和新生成的群聊信息存储在 Group、GroupMember 表中，并实时更新群成员个数。
然后，B 用户带着随机码加入群聊时，手机客户端向服务器后端发送请求，验证随机码是否有效。后台服务检查随机码是否存在于缓存中，如果存在，则校验通过。
然后，根据 Group 中的成员个数，来判断当前群成员是否满员（目前普通用户创建的群聊人数最多为 500 人）。
如果验证通过，后台将用户 B 添加到群成员表 GroupMember 中，并返回成功响应。
面试官：如果有多个用户同时加入，MySQL 数据库如何保证群成员不会超过最大值呢？
我：有两种方式可以解决。一个是通过 MySQL 的事务，将获取 Group 群成员数和插入 GroupMember 表操作放在同一个事务里，但是这样可能带来锁表的问题，性能较差。
另一种方式是采用 redis 的原子性命令incr 来记录群聊的个数，其中 key 为群聊ID，value 为当前群成员个数。
当新增群员时，首先将该群聊的人数通过 incr 命令加一，然后获取群成员个数。如果群员个数大于最大值，则减一后返回群成员已满的提示。
使用 Redis 的好处是可以快速响应，并且可以利用 Redis 的原子特性避免并发问题，在电商系统中也常常使用类似的策略来防止超卖问题。
同时，在面对面建群的过程中相当重要的能力是标识用户的区域，比如 50 米以内。这个可以用到 Redis 的 GeoHash 算法，来获取一个范围内的所有用户信息。
由于篇幅有限，这里不展开赘述，想了解更多位置算法相关的细节，可以看我之前的文章：听说你会架构设计？来，弄一个公交&地铁乘车系统。
面试官：嗯不错，那你再讲一下群聊系统里的消息发送和接收吧！
我：当某个成员在微信群里发言，系统需要处理消息的分发、通知其他成员、以及确保消息的显示。
在群聊系统中保存和展示用户的图片、视频或音频数据时，通常需要将元数据和文件分开存储。
其中元数据存储在 MySQL 集群，文件数据存储在分布式对象存储集群中。
消息发送和接收的时序图如下所示：
除了上述建群功能中提到的用户表和群组表以外，存储元数据还需要以下表结构：
面试官：我们时常看到群聊有 n 个未读消息，这个是怎么设计的呢？
我：MessageState 表记录了用户的未读消息数，想要获取用户的消息未读数时，只需要客户端调用一下接口查询即可获取，这个接口将每个群的未读个数加起来，统一返回给客户端，然后借助手机的 SDK 推送功能加载到用户手机上。
面试官：就这么简单吗，可以优化一下不？
我：（内心 OS，性能确实很差，就等着你问呢）是的，我们需要优化一下，首先 MySQL 查询 select count 类型的语句时，都会触发全表扫描，所以每次加载消息未读数都很慢。
为了查询性能考虑，我们可以将用户的消息数量存入 Redis，并实时记录一个未读数值。并且，当未读数大于 99 时，就将未读数值置为 100 且不再增加。
当推送用户消息时，只要未读数为 100，就将推送消息数设置为 99+，以此来提升存储的性能和交互的效率。
面试官：嗯，目前几乎所有的消息推送功能都是这么设计的。那你再说一下 10 亿用户的群聊系统应该如何在高并发，海量数据下保证高性能和高可用吧！
我：我想到了几个点，比如采用集群部署、消息队列、多线程、缓存等。
在群聊系统中，我们用到了分布式可扩展的思想，无论是长连接服务、消息推送服务，还是数据库以及分布式文件存储服务，都是集群部署。
一方面防止单体故障，另一方面可以根据业务来进行弹性伸缩，提升了系统的高可用性。
在消息推送时，由于消息量和用户量很多，所以我们将消息放到消息队列（比如 Kafka）中异步进行消费和推送，来进行流量削峰，防止数据太多将服务打崩。
在消息写入和消费时，可以多线程操作，一方面节省了硬件开销，不至于部署太多机器。另一方面提升了效率，毕竟多个流水线工作肯定比单打独斗更快。
缓存前面已经说到了，除了建群时记录 code，加群时记录群成员数，我们还可以缓存群聊里最近一段时间的消息，防止每个用户都去 DB 拉取一遍数据，这提升了消息查阅的效率。
除此之外，为了节省成本，可以记录流量的高峰时间段，根据时间段来定时扩缩节点（当然，这只是为了成本考虑，在实际业务中这点开销不算什么大问题）。
面试官：嗯不错，实际上的架构中也没有节省这些资源，而是把重心放在了用户体验上。（看了看表）OK，那今天的面试就到这，你有什么想问的吗？
我：（内心 OS，有点慌，但是不能表现出来）由于时间有限，之前对系统高并发、高性能的设计，以及对海量数据的处理浅尝辄止，这在系统设计的面试中占比如何？
面试官：整体想得比较全，但是还不够细节。当然，也可能是时间不充分的原因，已经还不错了！
我：（内心 OS，借你吉言）再想问一下，如果我把这些写出来，会有读者给我点赞、分享、加入在看吗？
面试官：……
群聊系统是社交应用的核心功能之一，每个社交产品几乎都有着群聊系统的身影：包括但不限于 QQ、微信、抖音、小红书等。
上述介绍的技术细节可能只是群聊系统的冰山一角，像常见的抢红包、群内音视频通话这些核心功能也充斥着大量的技术难点。
但正是有了这些功能，才让我们使用的 App 变得更加有趣。而这，可能也是技术和架构的魅力所在吧~
京公网安备 11010802035086号