18-05-9

1，我们有个业务场景是一次消息通知需要通知1万人，但一次只需要随机通知10个人，第二次随机通知剩余用户里的10个人，依此类推，

2，目前实时通信服务号的逻辑是，创建一个服务号会话，标记用户到这个服务号里
一次消息通知发给服务号即可，服务号里的所有用户即可收到消息。

3，我们想到一个方案是做一个数据记录，第一次把会话写到记录里，请求记录的未发送的10个人，用Leancloud实时通信群聊给这10个人发消息，然后标记10已发送的10个人，第二次请求记录里未发送的人来通知，以此类推

4，所以现在不知道能不能利用Leancloud实时通讯服务号定制化开发，或者有没有其他更好的方案，求大神们指教

QQ截图20180509120345.png1874x763 131 KB

jyspermLeanEngine / Node.js 工程师
18-05-9

你好，我们的实时通讯服务号本身是没有这个「分批随机发送消息给部分用户」的功能的，可能需要你自行实现这部分逻辑（例如写成云引擎代码），用「给任意用户单独发消息」的 API 来发消息，这个 API 一次最多发 20 个用户，再多的话需要多次调用。

https://leancloud.cn/docs/realtime_rest_api_v2.html#hash-11626561231

现在不太清楚你是否是要「每批随机发 10 人」，总共发 1000 批把所有的用户都发到。如果是这样的话可能 LeanCache（Redis）会比较适合存储这个「已经发给了哪些人」的状态。大概就是先将所有用户加到一个 Set 里，然后用 SRANDMEMBER 每次随机取出 10 个用户，调用「给任意用户单独发消息」的 API 来发消息。Redis 的 Set 类型非常适合这个场景，总人数在十几万这个级别都不会有问题。

https://leancloud.cn/docs/leancache_guide.html

如果发的用户较少（例如少于 10000），或者只发几批（不把所有用户都发到，例如 10 批）的话，也可以考虑用云存储来存储已发的状态，只不过针对这种场景，能够支持的人数可能比 LeanCache 稍微少一些。