是这样的,我们做了一个公众号工具,用户群A具有群发模板消息的能力,用户群B是接收模板消息。
用户A在页面上填写内容之后提交之后,由于是群发的,时间可能会非常长,所以我们做成了异步处理,把用户的消息都push到一个队列之中,push成功了就返回给用户A成功。用户A前端操作就结束了。
之后后台每一段时间就扫描一次队列,如果队列中有数据,就执行群发推送。
现在出了这样一个问题,公众号那边开始出现不确定因素(有时是api变更,有时是服务器50X错误),导致我这边队列推送开始出现失败的情况。像网络超时或临时性错误还好,可以用定时重试的方法解决这个问题。
但如果是服务器api更换这种,我们这边推送就会100%失败,用户群B就永远也收不到消息,然而这种错误在用户A这边是看不到的,会以为发送成功(因为改成异步了嘛,push到队列中就结束了,也不能一直盯着这个大推送列表看,时间可能会非常久)
所以想问有没有什么设计方案能让公众号api服务器出问题时,用户A这侧能感知到是公众号服务器出了问题。
自己考虑过可以将推送列表状态暴露给用户A看,用户A能自己看到推送的状态。然而感觉并不直观,用户A可能不会去看这个列表。
是这样的,我们做了一个公众号工具,用户群A具有群发模板消息的能力,用户群B是接收模板消息。
用户A在页面上填写内容之后提交之后,由于是群发的,时间可能会非常长,所以我们做成了异步处理,把用户的消息都push到一个队列之中,push成功了就返回给用户A成功。用户A前端操作就结束了。
之后后台每一段时间就扫描一次队列,如果队列中有数据,就执行群发推送。
现在出了这样一个问题,公众号那边开始出现不确定因素(有时是api变更,有时是服务器50X错误),导致我这边队列推送开始出现失败的情况。像网络超时或临时性错误还好,可以用定时重试的方法解决这个问题。
但如果是服务器api更换这种,我们这边推送就会100%失败,用户群B就永远也收不到消息,然而这种错误在用户A这边是看不到的,会以为发送成功(因为改成异步了嘛,push到队列中就结束了,也不能一直盯着这个大推送列表看,时间可能会非常久)
所以想问有没有什么设计方案能让公众号api服务器出问题时,用户A这侧能感知到是公众号服务器出了问题。
自己考虑过可以将推送列表状态暴露给用户A看,用户A能自己看到推送的状态。然而感觉并不直观,用户A可能不会去看这个列表。
这个解决方法是不是不太合理,用户A就算获取到异常信息,处理问题的还是你们自己,你给他个错误的意义何在,我怎么觉得你应该先解决服务器api的问题是关键
写错误日志。