求教如何支撑IM中10万人群的大规模群聊技术实现

大佬们，如何在IM中支撑起10w级别或者更大规模的群聊。现在我有几个方法供参考：
1. 消息合并转发，当消息达到一定量或者一定的采集时间之后才会将消息合并转发出去。
2. 对群聊消息的qps做限制，超过限制拒绝发送。
3. 更改推拉方式，我现在用的消息下发主要通过服务端路由主动发送，可以由主动推消息改为客户端定时拉消息。

以上三种方式均对消息的实时性有所影响，想请教一下有没有更好的方法对大规模群聊消息做优化。

im中，群聊几乎是所有除了音视频外最难搞的功能（主要是性能方面）。
千人群是一个槛，万人群是一座山，10万人群那就是山上的另一个峰，一个比一个难，方案不是三两句话能说的清楚。

你可以把我专门整理在这里的群聊文章，先都看一遍，然后再从全局进行考虑和设计：
http://www.52im.net/forum.php?mo ... on=view&ctid=20

引用：JackJiang 发表于 2021-11-29 15:05
im中，群聊几乎是所有除了音视频外最难搞的功能（主要是性能方面）。
千人群是一个槛，万人群是一座山，10 ...

谢谢大佬

能保证低延迟投递的写扩散在当前技术条件下是不现实的，从成本上来考虑也不能写扩散；
但是单凭客户端来定期拉，也是不现实的，容易引起读流量风暴；

需要工程策略上做一定优化，比如：
1. 高频消息聚合推送，只下发最后一条消息，由客户端拉中间的空洞
2. 离线推送优化，降低推送间隔；
3. 部分非核心场景做产品层面的tradeoff，比如表情，点赞，已读回执等能不上就不上，避免推送放大

引用：wangjil_BI85P 发表于 2021-12-01 08:52
能保证低延迟投递的写扩散在当前技术条件下是不现实的，从成本上来考虑也不能写扩散；
但是单凭客户端来定 ...

思路对头，产品逻辑上10万人群扩散写确实会形成消息风暴，只能在技术上逆逻辑去实现（就是想办法聚合、合并、跳跃这些思路去取巧实现，避它的锋芒）。