如何优雅的提升轮询速度

为什么不考虑 Websocket ？

用 laravel 自带的队列并发请求好了

你这边有 20 万台设备，但请求接口的并发限制为 10QPS，然后 20 万台设备的每一台都需要快速的轮询接口查询设备状态，是这意思吗？快速是指多长时间更新一次？

我总感觉不对劲。是不是这么回事： 库里有 20 万台设备，这些设备是某些物联网设备之类的，比如家庭监控，智能门锁，火警报警器之类的，某国企提供的，他们有自己的系统自己的管理方式，就象一个黑盒，无从知道里面的具体情况是什么，也无从干涉比如改支持 websocket 之类的，但是，这些设备，都有唯一地址或者标识，都提供一个查询接口，可以对它通过某种方式，比如 http 请求，向其询问这些设备本身工作正常不正常。这个 10 QPS 也是这些设备的限制，每秒不能请求超过 10 次。

如果是物联网设备， 10QPS 足够了，题主的挑战可能是在 1 秒内发送 20 万个 http 请求并处理 20 万请求得到 20 万的响应并入库，这个更有挑战性。如果要耗尽这 10QPS，题主每秒要发 200 万请求。

可是物联网设备一般都是主动请求，主动向网关报备状态的。

所以我还是不理解场景到底是什么。

mark

主要是看对面的硬件设备的通信协议是啥，如果是 mqtt 那就简单了，订阅好主题，定时上报，统一处理就好了，而且对于实时更新设备状态，这个需求可以考虑一下，因为很多数据都无意义，只有打开设备连接即主动读取的时候才有意义；

如果还是传统的 http，常规做法是使用轮询，按照你的描述是对方提供查询设备状态的 API 接口去查询，但是会存在很多问题：

1、多少秒轮询一次？如果遇到网络故障或者延迟，上一次轮询还没有结束，下一次又开始了要怎么处理冲突？ 2、如果因为网络故障卡住了导致后续查询无法进行，要如何处理？

我的意见是：

1、其实本身这个需求就有很大的问题，20 万台设备，就算处理能力能达到要求，数据量也大的惊人。既然是提供的三方 API 查询，本质上还是查询的对方的数据库，实时更新状态这个需求可不可以更改，改为 2 小时或者一天 n 次这样去处理？当有需要查看一台或者多台设备的时候再使用轮询，这样效率会不会更高一些？

2、优化数据存储，如我所说，绝大部分数据都是无用数据，那么这个时候可以使用 mongodb 去维护设备状态（物联网一般都是用 mongo 来保存设备状态），每次读取就去更新设备状态，记录更新时间，而我设定好的时间（例如每天的 8 点，14 点，17 点，22 点）这些时间点读取的数据才计入到读取记录里，不然一个月数据量就爆炸了。

发 20W 的请求都要一个小时了吧

1. 你自己服务器的带宽限制
2. 短时间大批量请求，协程或者异步请求 如果用传统框架试试用这个： guzzle http 批量请求

每秒钟只能更新 10 台设备的信息，20 万 / 10 (qps) / 60 (秒) / 60 (分) = 5.56 （小时）

即楼主这边的设备最大延迟就是 5.56 个小时

性能的瓶颈不在楼主这边，而是在接口提供方

楼主的需求应该是如何最大化的利用这 10QPS 去及时获取到最新的设备信息

把设备编号 1,2,3,4,5...N, 只需要把 10 的 QPS 打满即可（最好留一点余量，以防超频请求失败）

第一秒获取 1-10

第二秒获取 11-20

。。。。

到了第 N 后指回 1 即可