一天大概会生成七八千量的订单数据，逐一去调用第三方支付接口支付。已有逻辑是使用定时任务同步执行的，每 5 秒执行一次，需要执行几个小时才能完成。怎么改造一下能快速处理完？

[typ1805]

[WangRicky]

分通道多个任务去处理，比如按照订单最后一位，那么就会提升 10 倍，或者对订单取模型，分割的方法有很多，这样不用引入新的中间件，而且对数据的进度，成功情况有更好的掌握

[hxndg]

典型的批处理任务？

[fiypig]

推荐用 Go

[AngryPanda]

这种支付过程是不需要用户参与的吗？

[daimameiwenti]

你用 queue 队列处理订单，一个个处理，OK 的就移除队列，不 OK 的就继续 offer

[zw1one]

1 、如果你要改动小的话，就在处理的地方加个线程池，多设置几个线程同时做支付发送就好了，注意 oom 问题。
2 、如果要改一改架构，上个 mq 提升系统可用性的话，我大概设计了个架构。
https://www.processon.com/view/link/6066cde95653bb5ceafdc638

[wsbnd9]

串行 变成 并行调度 跟语言就没啥关系了

[tcsky]

你这个不是常规支付接入吧， 是客户下单后用自己账号代付么？多准备几个账号

[WhereverYouGo]

@zw1one #26 牛逼啊 [赞]

[cpstar]

为什么不说说为什么已有逻辑设定 5 秒钟搞一次，
5*8000=40000/3600=11.111 ，那必然半天都在处理订单了。
我只想知道当初是哪个~哔~设计的这个逻辑。

[cpstar]

换句话讲，能保证每一个单子 5 秒钟能处理完？如果没有处理完的，下一个单子怎么办？
这特么没学过边界测试吧。。。

[corningsun]

用阻塞队列就好啦
一个线程捞任务到队列，如果队列满了就等待
再搞一个消费线程池，直接从队列取，队列满了就等待。（需要控制消费线程池的大小，保证不把支付接口压垮就好）

[corningsun]

修正下：再搞一个消费线程池，直接从队列取，队列空了就等待

[arvinsilm]

定时任务一般是一次取出全部未执行的数据去执行，没有未执行的数据则等待下次执行。不是每次只取一条数据。。。。。

[pcbl]

平均 10 秒一个新订单，5 秒去执行一次，可以接受，既不会大量积压也不会频繁请求

[pcbl]

不更改原有逻辑不增加中间功能的情况下可以把 5 秒改成一秒，每间隔一秒钟就去获取一个最早生成的未处理的订单，添加一个处理中标记，执行完成后标记为已处理

[dzdh]

@typ1805 java 不是有 threadpool 么。

[stardust21]

Java 的话直接用固定数量的线程池解决？

[tjq]

可以试试 PowerJob 这个任务调度框架，支持 MapReduce 分布式计算，很符合你的场景。

[hahasong]

开个 threadpool 不就行了 试出 api 的极限 设置一个 80%的大小