微信群为什么上限是500人，IM设计系统中的群聊的设计难点

前言

微信是我们常见的应用，不知道大家有没有注意到微信群聊有人数限制，那么这个就是是不能做到还是不想做到呢。为什么是500呢？其中有什么说法吗。这期视频讲从技术的角度讲解一下群聊在技术上面的复杂性。
已经写过相关IM的文章如下，B站上面有对应的视频。去B站关注我呐！
目前已经写的IM的文章
分布式websocket即时通信(IM)系统构建指南【第七期】
分布式websocket即时通信(IM)系统保证消息可靠性【第八期】
分布式websocket IM聊天系统相关问题问答【第九期】
什么？websocket也有权限！这个应该怎么做？【第十期】
分布式ID是什么，以美团Leaf为例改造融入自己项目【第十一期】
IM聊天系统为什么需要做消息幂等？如何使用Redis以及Lua脚本做消息幂等【第12期】
哔哩哔哩后续会发视频。大家可以关注的b站账号。
可以直接跳转B站观看视频 点点关注

群聊情况下的并发

我们来思考一下发送一条消息需要经历哪些过程，在之前那期关于微信的视频中提到了一条消息的发送流程。这下我们换个场景来思考一下。在一个五百人的群中发送一条消息会发生什么。假设五百个同时在线，那么一个用户发送一条消息，需要让五百人都同时收到这个消息，对于服务器来说，一条消息基本对应的就是处理五百个用户的需求。微信群一分种可能会有多少消息呢，就假设500人一人发一条。那就是服务器需要同时处理500乘500。就假设微信群有只有100个这样的群聊。那么，系统每分钟需要处理的消息发送量为100 * 500 * 1 = 50,000条，消息接收并发量为100 * 500 * 1 * (500-1) = 24,950,000条。可想而知。对与真实情况下的服务器压力有多大。

在从用户体验的角度来说一下。在一个超大的群聊中，消息量通常非常大，这可能会导致用户错过重要信息，降低用户体验。限制群聊人数有助于保持群聊的可管理性和信息的可追踪性。也可以方便管理，对于维护群秩序、处理纠纷、审核新成员等功能的开发也会变得更加的容易。

如何应对IM系统中群聊的高并发以及如何存储

通过上面的举例子，我们可以清楚的知道IM系统中并发的设计是一个难点。以及海量数据的存储也是一个难点。那么微信是如何做的呢。
这里要提到微信的存储方面的小常识。微信的聊天记录是存储在用户的手机上面的，前面有一期破解微信数据库的视频，可以从那里也可以得知微信的数据库存储在本地。这个地方就对应着存储模型使用的是读扩散。意思就是一个人在五百个人的群里面发送消息，那么这五个个人都需要在自己本地的数据库sqlite里面存储一条消息。 这样做的好处就是读取消息的时候会比较的方便，坏处就是插入的时候会比较的麻烦，当然前提是数据库全部在云端服务器的话那么插入数据就会有很大的压力，微信是插入本地的还好一点，猜测离线数据的会放到云端，也就是数据库，当用户拉取到消息的时候会进行删除。
第二个难点就是微信的高并发是怎么处理的。
首先如果回答这个问题从比较大的角度上面的回答肯定涉及到分布式架构，消息队列，负载均衡，数据库优化，缓存策略等等。但是关键还是要从消息的推拉模型来进行分析。先有的消息推送模型，然后对技术进行选型。群聊的时候采用的方式不是那种发一条消息推送一条消息的方式。采用的是消息拉取的方式。在线用户会进行拉取，会带上这个群标识和群最小消息id，一次性拉取完当前群里面所有的消息。IM系统中群聊消息推送模型有很多讨论的空间。

后续

后续会继续完善自己的开源项目然后发布代码出来。本期视频可以做为一个兴趣点了解为什么微信群有人数限制，也可以算作了解微信群如何计算并发数，也可以当做对于IM设计难点进行思考。欢迎对于IM的相关问题进行讨论。