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

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

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

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

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

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

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

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

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

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