场景
票据验真需要调用接口。接口需要远程调用，速度不是恨快。而数据库的票据数量却可以很多。 所以需要验真策略。 控制数据，避免大量数据造成压力，甚至阻塞。
新票据需要验真。
验真不通过的票据，需要定时验真。
解决方案
多少次也无法验真通过的票(从失败任务中排除)
可能由于金额，或者日期不对。 造成不通过。如果不改对金额，即使再验一万次，也是不通过。
问题是改票据成本太高，有的票据甚至连图片也找不到了，想改也没法改。
但是状态是失败， 定时任务能跑到。会造成资源浪费。
方案：
改为不受定时任务触发的状态。例如29。
这样轮询不到这样的票了。
设置优先级，提高命中率
有的票据，随着时间可能会验真通过，例如查无此票的。 今天没有，明天可能会有。
这样的不应排除出去。 但是要设计优先级。 日期近的优先查询出来，order by create_date desc 。
这样即使之前有很多张不过的，不会影响现行任务。
除了改状态还可以根据code写代码逻辑
status只有几种比较方便。
code种类很多。根据code进行细分的话，有有点也有缺点。
优点： 根据code可以制定出最合适的策略。
缺点： 需要对每个code的应对方式很熟悉，而且代码或sql中可能要用多in等条件，比较凌乱。
其他
默认排序引起的问题
直接按照默认的排序，这样基本根据id排序，是不合理的：
1、早期的数据有很多过不了的数据。(效率不高)
2、如果失败票据太多，后面的有可能永远都轮询不到。
根据时间倒序的话，比较合理：
1、命中率高。
2、相同配置的情况下，对现行业务的支持最好。
java代码中的轮询策略
出于性能考虑。 数据库可能有很多条，但是java只建议取一定条数。 然后乱序。
sql中的乱序 和 java中的乱序
sql中使用乱序覆盖率高。
也就是说再冷门的数据也有可能筛选出来。
java中使用乱序：
因为一般都是拿出一定数量，然后再随机一部分。有助于规避某次错误数据， 反复提交。
