超级群组

野火支持读扩散的群，我们称之为超级群组，顾名思义，超级群组可以支持无限制的群组成员和群消息，下面看一下简单介绍吧。

1. 群消息扩散模型

一种是写扩散，在群里发送一条消息，就会在群内每个用户的时间线上插入一条消息。有种优化的方式是，插入的是消息id，读取消息时先读取到消息id再读取消息。写扩散方式的优点是实现比较简单；缺点是太占用空间，另外写数据库的数量跟群的大小成正比，还有如果有太多消息未同步，没有办法按照会话舍弃旧消息。所以基于写扩散的群都不能太大，一般500人。常见的写扩散的有微信。

另外一种就是读扩散，在群里发送一条消息，在群的时间线上插入一条消息。当用户同步消息时会检查自己的群，按照群的时间线来读取消息。这种方式的优点是写入只有一次，写入比较简单，可以支持超级大群；缺点就是拉取消息比较复杂，每次拉取需要计算哪些群组有消息变更再依次拉取。读扩散的模式可以支持很大的群，电报和QQ都是读扩散实现的。

群消息的扩散模型一般都是这两种，更详细的说明可以在网上找到。野火之前的实现方式就是优化过的写扩散方式。

2. 野火的超级群组

写扩散模型的问题就是不能支持大群，所以我们在专业版上研发了读扩散模式，之前的写扩散模式也继续保留。在群的属性中添加了一个superGroup的属性来区分是写扩散还是读扩散。这样一般的群可以继续使用写扩散的方式，公司全员群或者成员数多的或者消息量大的客户群可以用读扩散的方式。而且普通群可以通过server api来转化为超级群组。

由于有了读扩散方式的支持，野火可以像电报一样，支持上万的群成员数，而且没有单点瓶颈，超级大群依赖整个系统的能力，不依赖单个服务的能力。另外针对消息的同步也做了优化，单个会话可以一次同步十万条消息。当然同步的只是消息ID+消息类型+存储属性。这样如果有十万以上的消息也瞬间就同步下来了。当客户端需要显示消息时，如果本地只同步下来消息ID，则会再去服务器同步消息内容。

3. 超级群组的代价

当然代价也是有的：首先是所有获取消息的接口都要改成异步的，因为有可能是消息已经同步到本地数据库了，也有可能本地还没有需要去服务器同步。其次搜索消息是个问题，因为很多消息其实只同步下来一个消息ID，而且本地消息量大会影响本地搜索的耗时，这个问题可以同步开发服务器端搜索来解决。还有不再支持送达报告，只支持阅读报告，因为送达报告其实没有太大用处而且太消耗性能就去掉了。还有不能支持单边远程删除消息。

4. 如何开启超级群组

首先客户端和服务器都需要升级到2023.4月中旬以后的版本。在IM服务的配置文件中，有如下配置:

## 超级群组策略
## 0 客户端创建普通群组，server api创建群组时，super_group确定是否超级群组；1 所有创建的群组都是超级群组;2 所有创建的群组都是普通群组;3 当普通群组超过${group.super_group_upgrade_threshold}指定的成员数时自动切换为超级群组，注意当成员时小于时不会切回普通群组，server api创建群组如果指定超级群组也会是超级群组。
group.super_group_create_strategy 0

##超级群组策略为3时，此配置为进行切换的成员数
group.super_group_upgrade_threshold 100

建议策略为0或者3。

5. 总结

当群组成员超过200人之后，超级群组相比于普通群组性能有着非常大的改善，而且群越大性能效果越明显，可以解决超级大群的技术难题。使用野火可以支持无限制群大小和无限制的消息量，可以做到媲美电报的体验。