大量支付订单轮询，各位有什么好的方法解决。

[liuawei]

声明一下领导给的时间在 3 个工作日完成任务，接入的支付方式比较多，微信(扫码，H5，小程序)、支付宝(扫码，H5，刷脸)，收钱吧，威富通等。
使用的是 Java 语言。目前 1 分钟差不多高峰有 300 单。目标是能支持一分钟 600 单。

[liuawei]

说明一下：300 单是有效订单，已经支付订单，参与轮询的订单大概是有效单的两倍。

[Raymon111111]

啥叫轮询

1 秒 10 单基本不用太考虑性能

[Vegetable]

是看订单有没有支付完成?
你们不是用回调的吗?再说清楚一点吧

[Moker]

4 方支付？

[PhpBestRubbish]

支付不是有回调吗，要轮询干嘛？

[1sbugou]

威富通。。呵呵

[liuawei]

@Raymon111111 就是查询订单支付状态。有的时候一次支付查询请求都需要 1 秒哦。

[liuawei]

@Moker 公司是做自助售卖机的，所以细分的支付方式有 10 几种。

[Mrun]

AMQ

[Moker]

订单状态对方有回调 等通知就好了 主动查询只是一个补偿 量很小 加上异步去请求就可以了

[liuawei]

@Vegetable 第一个轮询会存在网络节点丢单情况，第二个比如支付宝反扫，刷脸支付会没有回调，会存在请求支付宝接口，支付宝接口 Socket 异常，我们这边异常，支付宝已经扣款成功。

还有例如威富通这种机构有的时候回调会有问题。

[arrow8899]

消息队列，设置多个线程同时消费，你开 20 个线程，查一次 1s，1 分钟也有 1200 单了

[liuawei]

@1sbugou 威富通遇到过一次不进行回调，还有就是关闭支付通道这种骚操作。

[skymei]

不同的支付类型放到不同的队列，开线程去对应的队列，1 分钟 600 单不算很大的量，应该是处理的过来.看你们的服务器配置以及代码部署方式了，要是有负载均衡，缓存的话基本不用担心。

[liuawei]

@Moker @arrow8899 消息队列考虑过，但是时间短，假如队列要改至少三个项目，H5，小程序，原生这些都是不同的项目。

[1sbugou]

@liuawei 威富通比较坑，毕竟它是自成一体的通道，不像其他银行和三方

[kingOfWorLd]

其实可以用消息队列的，每次支付成功，如果有回调成功了，就返回成功，如果没有回调，需要主动查询的，就抛到消息队列中，如果消息队列查询成功，更新订单状态，如果查询失败，再接着抛进消息队列，记录查询失败的次数，如果失败次数大于 5 次，那么就要进入反馈系统了，人工去查询，干预。

[liuawei]

@kingOfWorLd 说了只有三个工作日，原生支付，H5, 小程序是不同的项目都要改，公司以前没有用过消息队列。

[liuawei]

目前自己的解决方案是，JOB 轮询，每种支付方式建立一个任务。 但是我们领导说也会存在丢单的情况，他的观念说，查询请求 0.5S+我们业务逻辑处理，下货 0.5S 。一分钟超过 100 单的话会存在有些订单轮询不到。

[mortonnex]

楼主怕不是对轮询有什么误解