发消息操作限制为 每分钟 60 次上限问题

[NPC_expired]

对于客户端主动发起的操作会按照操作类型限制其频率。发消息操作限制为 每分钟 60 次，历史消息查询操作限制为 每分钟 120 次，其它类型操作包括加入对话、离开对话、登录服务、退出服务等均限制为 每分钟 30 次。当调用超过限制时，云端会丢弃超出的消息。

目前我们的客服功能参与一个城市下的全部会话，会话背景信息查询的次数会比普通角色频繁。我们目前查询会话的限制是每分钟30次。

希望调整上限。

[ylgrgyq]

你好，想问一下这个查询是否有缓存？是一个会话查完使用完毕之后直接丢弃，还是会存下来之后复用？
另一个问题是，查询时是否能通过 查询约束 https://leancloud.cn/docs/rest_api.html#查询约束 来批量的查询会话？

[hiabp]

无缓存，缓存跟业务规则有冲突，目前功能不仅要查会话，还需要查消息历史，用最近一条消息的发送者比较conversation中的角色，属于用js-sdk 直接查询的类型，客服每天分配的会话会上几千个，可以理解为万级别。背景信息依赖于conversation定义中的附加字段。

[ylgrgyq]

你好，扩大查询会话上限确实很难，因为即使扩大了查询限制但查询过多导致查询时间过长，一样会影响你们的服务。所以我们想进一步了解你们服务内部实现机制，一定有方法能够在满足需求的基础上，减少查询次数的。

对于上面业务的描述还有诸多不明白的地方。

“目前功能不仅要查会话，还需要查消息历史，用最近一条消息的发送者比较conversation中的角色”
是说这个客服会查询一个会话的历史消息，找到最近一条消息的发送者，然后这个会话中有个属性存储的是每个成员的角色，不同角色有不同的权限。查询会话主要原因就是，需要找到最近一条消息发送者之后，查询会话内角色属性获取到这个最后一条消息发送者的角色是吗？

[ylgrgyq]

你好，可有看到我的回复？

[hiabp]

对的。你理解的没错。是这样的。下午在开会。没顾上看。

[ylgrgyq]

客服在被分配上千个会话之后，是以轮训的方式去遍历所有分配的会话，然后查询最后发消息人的角色吗？或者在什么情况下，这个客服会去查看某个会话最后发消息人的角色？

另外是否能告知一下为什么查询请求会超过一分钟 30 次的限制？

这里除了查询操作本身可能耗时较大以外，大量的查询还会导致连接通道被返回的结果占满，而影响实时消息的收发。

[Sunng]

你好，这种使用场景会给系统带来很大的浪费和压力，强烈不推荐使用。

如果有监控所有对话的需求，可以通过定时拉取应用层面的聊天记录，或者通过云引擎 messageSent hook 同步记录到相关的系统来获取。不要让某个帐号加入所有的对话，否则这个帐号登录时会获取所有对话的离线消息，造成严重的压力。

如果这个帐号有发消息的需求，我们提供的 REST API 可以在不加入对话的情况下发送消息到任何对话。

我们目前已经观察到了这种使用方式对系统性能造成的影响，希望通过我们描述的方式进行修改，否则我们在系统和规则层面会一些限制，以确保系统稳定。