先澄清:不是看“服务器台数”,物联网云平台是集群化架构,核心限制是「并发长连接数」,而不是CPU/内存单一指标。
> 我们平时说的“一台”,如果是单台物理机/虚拟机,和商用物联网平台集群(阿里云IoT、OneNET、ThingsBoard、EMQX+JetLinks)上限完全不一样。
1、单台服务器(独立机器,单机部署)
物联网接入瓶颈绝大多数是 TCP长连接(MQTT)
Linux默认参数很小:`ulimit -n` 文件句柄限制,默认一般1024。
调优后(epoll,内核参数:`fs.file-max`、`tcp_tw_reuse`等):
- 普通4核8G云服务器:2万~5万并发长连接(消息量不大,只保心跳,上报频率低,如几分钟上报一次)
- 8核16G高配单机:5万~10万并发连接
> ⚠重点:如果设备上报频繁(秒级上报遥测),单机连接数会大幅下降,可能只能扛1万甚至几千。
> 一旦消息吞吐大,瓶颈从【连接数】变成【消息队列、数据库、CPU】。
> 区分两个概念:
> 1. 并发在线设备:同时连着平台的设备(长连接)
> 2. 设备档案总数:平台数据库里注册过的全部设备(可以远大于并发在线,很多设备休眠离线)
> 例:单机可以存100万设备档案,但同一时间只能在线5万台。
2、开源方案集群(EMQX + JetLinks / ThingsBoard)
EMQX是MQTT接入层,横向扩容,接入层和业务层分离:
- EMQX集群:每节点可承载50万左右并发连接(高配物理机),集群叠加;
- 整套平台(含规则引擎、时序库):
- 小规模集群(3节点EMQX):100万~200万并发在线
- 大型集群:千万级并发(需要大量节点+优化,成本很高)
3、公有云商用物联网平台(阿里云IoT、移动OneNET、华为云IoT)
这类平台是超大分布式集群:
- 单租户上限:百万~千万级并发在线设备(看你购买的规格,有连接数配额)
- 底层整个平台:亿级设备档案、千万级并发连接。
关键影响上限的4个核心因素
1. 长连接心跳:心跳越短,服务器压力越大。很多电表/传感器30s~5min心跳,连接数可以拉很高;1s心跳会大幅降低上限。
2. 消息上报频率
- 低频率:几分钟上报一次 → 瓶颈是TCP连接数
- 高频上报(秒级) → 瓶颈变成消息吞吐、时序数据库写入
3. 设备协议
- MQTT长连接:占用文件句柄,连接数上限低
- CoAP/HTTP短连接:不占用长连接,并发在线设备数可以更高,但大量频繁请求会压垮网关
4. 平台组件分工
✅ 最佳架构:接入网关(EMQX)单独集群,和业务、数据库分开,接入层只管维持连接和转发消息,不做复杂计算。如果把接入、规则引擎、时序数据库全塞同一台机器,连接数会缩水非常严重。
简单参考表
| 部署形态 | 最大并发在线设备 | 备注 |
| 4核8G 单机 | 2万~5万 | 低上报频率,仅MQTT接入 |
| 8核16G 单机 | 5万~10万 | 心跳≥30s,少量消息 |
| EMQX 3节点集群 | 100万~200万 | 接入层独立,业务单独服务器 |
| 公有云IoT平台租户 | 百万~千万 | 按量购买连接配额 |
工程上的经验建议
> 不要把单机跑满,生产环境预留30%以上余量。
> 例如:规划5万在线设备,单机选型按3.5万做预留,防止突发上线、消息风暴。
补充:你选型时要分清需求
1. 你的场景是:大量设备休眠,同时在线少(比如野外传感器,大部分离线)
→ 重点看【设备档案总数】,并发连接压力不大
2. 场景是:所有设备一直在线实时上报(风机、电表、工控终端)
→ 重点看【并发长连接数 + 消息TPS】
官方微信
天猫店铺
京东店铺
销售王经理