评论

关于云函数推送订阅消息的坑和痛点,我是这样解决的。

解决利用云函数推送订阅消息的坑以及痛点

目前我遇到的场景是这样的。

以下所有功能都是基于云开发

场景:收集用户推送信息,然后有推送需求再统一推送。(先收集并储存用户的推送请求到一个集合A,并设置为false,推送成功后设置为true,未成功的用户依旧为false,这样来判断用户推送的成功率)

坑来了!

坑1:云函数只能读取100(官方已更新至1000)条数据,也就是你一次只能推送给1000个人,数据需求量大,比如你有1万用户,难道重复10次?

解决方案:我们可以先读取所有数据的集合,然后再循环推送。

参考链接:https://developers.weixin.qq.com/miniprogram/dev/wxcloud/reference-sdk-api/database/collection/Collection.get.html

坑2: 接坑1的需求,由于云函数的运行内存为256M,当我们数据量较大的时候,云函数就处理不过来,会报错如下。

解决方案:这个时候我们就需要开启本地调试了,开启本地调试,再通过开发者工具,来启动推送命令,这样,就很少会报错了,即使报错,也会先推送完很多任务。

坑3: 接坑1,坑2的需求,我们都将推送用户储存到了A集合,如果在推送的过程中由于时间差或者某些不特定因素的关系,当a介绍到了消息,z还没有由于某些因素没有推送到,需要重新推送,但此时a已经又重新打开了小程序并将推送需求储存到了集合A,这样一来,我们是不是又给A重复推送了一次。

解决方案:我们可以在推送前,添加一个新的集合B,在云函数修改,把下一轮要接收订阅消息的用户储存到B,这样一来,是不是A和B就都互不影响了。

再说的通俗易懂点,就是我们先将一部分人带到一个A会议室,等要公布新消息的时候,我们把门关上了,不让别人再进来,把后面到来的人带到B会议室,依次类推。

这样做的好处就是用户不会收到2次相同的消息,同时还能判断推送的成功率。而且在云函数后端就能自主完成,不需要重新发布代码进行审核!

如果大佬们有更好的意见,可以留言共同探讨。

低端程序员一枚,我只是将我的一个处理经验分享给大家,不喜勿喷。



最后一次编辑于  04-10  
点赞 0
收藏
评论

4 个评论

  • 王少华
    王少华
    05-14

    云函数可以配置内存的,默认256

    05-14
    赞同
    回复
  • 郑旭东
    郑旭东
    04-10

    limit最大值已经从100调整到1000了。

    04-10
    赞同
    回复 1
    • 是此木柴吗?
      是此木柴吗?
      04-10
      对我来说还是不够用,而且云函数根本处理不过来
      04-10
      回复
  • wang li
    wang li
    04-10

    看的我一头雾水

    04-10
    赞同
    回复
  • 哈
    04-10

    每次都用本地调试吗?

    04-10
    赞同
    回复 3
登录 后发表内容