你的这两种方案的主体思路仍然是在服务器端用Swoole的周期性定时器函数swoole_timer_tick定时轮询数据库,2万个Swoole定时器不是性能瓶颈,定时器回调函数里的数据库轮询操作才是性能瓶颈.
而且这样的设计也体现不出Swoole事件驱动的编程思想,你可以考虑使用Redis提供的消息驱动的订阅发布功能PubSub,具体操作就是:
1.每个客户端(物联网设备)保持一个到Swoole的长连接(协议任选,如MQTT).
2.每个长连接在服务器端用Swoole内置的异步Redis客户端订阅(Sub)一个频道,频道名假设为设备的MAC地址,做到唯一.
3.每当有某个设备的数据写入数据库时,写入操作的同时,使用Redis客户端发布(Pub)一条消息到对应设备的Redis频道,因为Redis的PubSub机制,该设备在第2步的订阅(Sub)操作会马上获取到这条消息,从而把这条消息推送给设备终端.