为什么要主动查询？

因为渠道通知不是100%成功，虽然绝大部分都是渠道通知成功的。

但是渠道有时候通知慢了(比如，隔了很久才通知)，或者渠道通知有问题了(比如通知成功但是网络有问题，支付公司都没有收到渠道的通知；暂时通知不成功，即通知的状态是非成功状态)。

时间

一般发往渠道之后，渠道立马(几s内)就会通知成功。

发往渠道30s之后，开始轮询。

为什么要等30s？因为大部分都是渠道通知成功的，没有通知成功的，基本上都是有问题的，job轮询只是备用手段，而不是主要手段。

5s轮询一次。

比如，一笔交易发往渠道30s之后，被job轮询出来，然后调用渠道查询是否支付成功。

也就是说，发往渠道30s之后，就会被job轮询处理，而且是5s轮询一次，如果觉得太频繁，可以控制频率，多加一个字段-下次发往渠道时间，

每次处理该数据的时候，下次发往渠道时间加30s，那么现在就是每隔30s才会被轮询一次。

次数越少的，越先处理。

先发往渠道，就先处理。而不是按创建订单的时间，因为渠道肯定是先处理先发往渠道的交易。

每隔5s轮询100条数据，一天几万s，所以总共轮询数据100*1万=100万，大概轮询100万数据。

显然，处理的数据不是特别多，但是上面说了，大部分数据都是渠道通知成功的，而不是job轮询成功的，所以也基本上够用了。

而且，如果数据量真的更大的话，可以拆分job，即不同业务(特别是数据量大的业务)用独立的job，这样处理的数据总量就更多了。