引用：Frank 发表于 2023-02-21 23:24
它家的国产化即时通水平太差，优化了半年，就搞不定两万用户树，加载速度超一分钟，特别的佩服。
本来想研 ...

买的融云私有化部署？

引用：服务落点计算中我们使用的是一致性哈希，群成员落点相对固定，所以落点一致的群成员我们可以合并成一次请求进行投递，这样就大幅提高了投递效率同时减少了服务的压力。

我理解的是 根据 群id 落点到同一组或一台服务

它家的国产化即时通水平太差，优化了半年，就搞不定两万用户树，加载速度超一分钟，特别的佩服。
本来想研究下,算了

引用：beijingit 发表于 2021-10-13 10:53
它家的国产化即时通水平太差，优化了半年，就搞不定两万用户树，加载速度超一分钟，特别的佩服。

哈哈哈，真的啊

能不能说说消息队列订阅的思路呢，不同的群聊进入同一个队列的话，那我是所有的IM服务都需要订阅所有的队列么?还是有针对性的订阅呢？

引用：JackJiang 发表于 2021-09-16 17:01
有啥问题

它家的国产化即时通水平太差，优化了半年，就搞不定两万用户树，加载速度超一分钟，特别的佩服。

引用：beijingit 发表于 2021-09-16 16:19
融云？！？

有啥问题

融云？！？

引用：JackJiang 发表于 2021-08-31 09:38
那上面说的落点，其实不太靠谱，因为一个用户有好多群，该以哪个群计算落点这显然没法固定。
识别大群这 ...

落点我是这么理解的，每个用户长连所在的机器对于他们的架构来说是固定的，优化前一条消息从投递服务一条消息到长连服务，优化后合并了uids。

干货

引用：椎锋陷陈 发表于 2021-08-31 09:28
JackJiang大佬好，由于我本身不是做服务端开发的，所以对文章中提及的几个地方有些疑问，烦请您能帮忙解答 ...

那上面说的落点，其实不太靠谱，因为一个用户有好多群，该以哪个群计算落点这显然没法固定。
识别大群这个大致是这样。

JackJiang大佬好，由于我本身不是做服务端开发的，所以对文章中提及的几个地方有些疑问，烦请您能帮忙解答一下

引用：服务落点计算中我们使用的是一致性哈希，群成员落点相对固定，所以落点一致的群成员我们可以合并成一次请求进行投递，这样就大幅提高了投递效率同时减少了服务的压力。

这里是说IM服务集群下有多个服务，比如5个，通过计算得出同一个群的群成员分别落在哪一个服务上，这样发送消息时只需要投递到这几个服务上，
然后由这几个服务再分发给对应的群成员吗？这样就把原本1:9999的消息分发分散为9999/5以减轻压力是吧？

引用：1秒钟往后端消息服务投递的消息数是消息服务处理上限的一半（留相应的能力处理其他消息），如果单台消息服务处理的 QPS 上限是 4000，那群组服务一秒往单台消息服务最多投递 2000 条。

就是通过识别超大群，针对这种超大群进行限流，限流标准是1秒钟投递的消息数最多只允许到达消息服务处理上限的一半，避免到达瓶颈是吧？