大家好，请问轮询用workerman有解决方案吗？谢谢大家！

1. 创建一个自定义进程，进程启动加载一个timer，timer定时收集一部分超过阈值的未完结订单，然后主动请求微信订单状态；
2. 创建webhook回调地址，用于接收异步通知消息；

这叫什么轮询，这不就是定时器定时调微信接口么，开个定时器调就完事了

我是这样干的，创建一个2秒定时器，下单时将订单信息存储在缓存中，在定时器里从缓存里读取订单信息向微信接口请求状态再更新。

为啥不是在前端处理定时呢，我们最近有个购票的业务，需要h5下单成功后去票务系统下单，但是靠微信异步通知再去票务系统下单会出现延迟问题 还有就是用户h5下单成功了 票务可能会出票失败，基于这个问题我们解决的方式是
1.前端用户支付成功后，开启定时请求后台订单支付结果查询接口
2.查询支付成功后对票务系统下单，票务系统下单成功，h5订单下单才算成功，票务系统失败，对该笔订单自动执行退款，退款失败提醒客户联系平台（一般不会出现这种情况）

做完这个小系统后 我思索了很久之前做过的支付，其实都存在支付问题，单纯的靠异步通知是解决不了订单的状态更新问题的，尤其前端要求下单成功后进入订单详情的场景，回调稍微延迟下，按我以前的做法都会面临客户明明支付成功了，进入订单却是待支付

微信下单，后端只是生成前端拉起支付的数据。若想后端获取该笔交易的支付状态，有以下方案：

1. 依据微信的支付通知回调。微信支付通知回调，会在用户成功支付后，下发给统一下单时配置的通知回调url；若业务服务器未按照微信官方约定返回给微信，微信会按照策略继续下发。
2. 使用定时器查询订单。使用定时器定时批量查询未完结订单，然后请求微信接口查询订单的支付状态。这种方式在订单量大的情况下会导致订单状态更新慢的问题。
3. 使用消息中间件。在每次下单时，将订单信息下发给消息中间件的生产者，在消息中间件的消费者里请求微信接口查询订单的支付状态并做更新。这里可设置消费者的数量及该笔交易消费次数和延时消费时间等，若某一笔交易在处理 M次*N秒 后仍然时未支付，则可认为该交易用户未支付。
4. 开发微信支付中台服务。将微信支付相关接口封装，在中台里开发服务接管微信的通知回调并做记录，需要保证中台服务的安全性，稳定性等。后续所有的支付业务和中台对接。
5. 前端轮询。该 "支付结果查询中" 的展示是仅面向用户的，轮训查询本系统的订单状态即可。
   目前，我们公司的做法是：1+3+4+5。

其实也很简单了
1、用户下单创建支付订单时，把支付信息也一起放到队列去
2、在创建一个时间任务去查询队列（消费），查询是否已经支付成功
3、查询用户未支付时，再放到队列去
4、设置一个阀值，轮询N次还是未支付情况下基本上用户是不会去支付了，所以可以关闭此条消费记录了（创建微信支付时，有一个支付超时，可以联动起来）

加个延迟队列，下单后塞进去5分钟后查看这条订单是否已经支付了，没支付就查一次微信判断就可以了吧