机房温湿度采集协议怎么选？TCP、UDP、SNMP对比与实战

机房里的温湿度数据看着简单，真要把它稳定、准实时地送进监控系统，协议选型往往比传感器本身更让人头疼。不少运维新手第一次接触以太网温湿度传感器时，都会对着“支持TCP、UDP、SNMP”这几个字发懵——到底该用哪个？三个都开行不行？项目验收时网管那边要的“标准接口”又是什么？

这篇文章就围绕机房温湿度采集的协议选型，把以太网传感器常用的三条路——TCP可靠传输、UDP轻量上报、SNMP网管兼容——掰开揉碎讲清楚。每种方案的适用场景、配置要点、常见坑都会涉及，最后给出可以直接抄作业的选型建议。不管你是刚接手机房动环的新人，还是正在做监控系统集成的工程师，这篇都能帮你少走不少弯路。

1. 机房温湿度采集场景拆解：先搞清楚你要传什么、给谁看

做协议选型之前，先别急着翻传感器说明书。我见过太多人一上来就讨论TCP和UDP哪个好，结果连现场采集的数据量、上报频率、接收端是谁都没弄明白。先把场景拆清楚，选型就是一道送分题。

1.1 机房温湿度数据的真实特征

机房温湿度采集和工业现场的设备数据有一个本质区别：它是一路慢变信号。温度从25.3℃跳到25.8℃可能需要几分钟甚至更久，湿度变化更慢。换句话说，就算你10秒钟采一次，相邻两次的数据差异通常也极其微小。

这就带来三个直接影响：

• 单包数据量极小。温湿度各一个浮点数，加上设备ID、时间戳、校验位，一般不超过64字节，一个以太网帧就能塞下。
• 对实时性的要求没那么苛刻。UPS掉电、服务器宕机这类故障要求秒级响应，但温湿度超标的恶化过程以分钟甚至小时计，延迟两三秒完全能接受。
• 数据需要长期连续性。你要的不是某一个瞬间的数值，而是能回溯的趋势曲线，这决定了“丢包”这件事到底有多严重。

1.2 接收端决定了你的协议下限

温湿度数据传到哪儿去，比怎么传更重要。我总结下来，机房场景的接收端无非三类：

第一类是动环监控主机或自建的采集服务。这类系统一般是自己在服务器上跑一个服务程序，监听某个端口收数据。你用什么协议往里扔都行，TCP、UDP、HTTP都有人用，自主权最大。

第二类是第三方网管平台，比如机房运维用的综合网管系统。这类平台通常会提供标准的北向接口，最常见的就是SNMP。因为网管系统要同时管理交换机、路由器、服务器、UPS等一堆设备，不可能为几十个温湿度传感器单独开发私有协议。

第三类是云平台或小程序。走MQTT或者HTTP上报，一般需要网关做协议转换，传感器本身很少直接上云。

搞清楚了这两点，再看TCP、UDP、SNMP三个候选人，思路就清晰了：它们不是取代关系，而是各自解决不同的问题。

2. TCP可靠传输方案：最稳，但不适合无脑用

很多人的第一反应是“TCP有三次握手、有确认重传，最可靠，就用它”。这个判断在点对点传输的大文件场景下没错，但在温湿度采集这个细分场景里，TCP的“可靠”是有代价的，而且代价经常被忽略。

2.1 TCP为什么让人觉得“可靠”

TCP的可靠来自一整套复杂的机制：三次握手建立连接、序列号保证有序、确认应答（ACK）保证送达、超时重传处理丢包、滑动窗口做流量控制、四次挥手优雅关闭。这套机制在网络状况不好时能自动重传，确保数据不丢不乱。

但注意，TCP保证的“可靠”是“字节流可靠到达对端”，不是“你的业务数据可靠处理”。简单说，TCP只能保证数据从A机器的网卡送到了B机器的内核缓冲区，至于B机器上的应用程序有没有正确处理、有没有写库，TCP一概不管。这个认知很多人到排查问题时才意识到。

2.2 温湿度采集用TCP的典型架构

假设你采购的以太网温湿度传感器支持TCP Client模式，最常见的组网是：传感器作为TCP客户端，主动连接监控服务器的TCP服务端口（比如8000），连接建立后周期性上报数据。

这种模式下，传感器的处理逻辑很简单：上电后尝试连接服务器，连上之后每隔N秒往连接里写一条数据，断线就重连。服务器端则需要维护一个连接池，接收多台传感器的数据。

从开发角度，传感器端的代码模型大致是这个样子：

import socket, time, json SERVER_IP = "192.168.1.100" SERVER_PORT = 8000 def read_sensor(): # 读取温湿度传感器的实际数值 return {"temp": 25.3, "humidity": 45.6} def main(): while True: try: sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(10) sock.connect((SERVER_IP, SERVER_PORT)) while True: data = json.dumps(read_sensor()) sock.sendall(data.encode("utf-8")) time.sleep(5) # 每5秒上报一次 except Exception as e: print(f"连接异常: {e}, 3秒后重连") time.sleep(3) finally: sock.close() if __name__ == "__main__": main()

服务器端就是典型的TCP服务端，需要处理多连接并发、连接超时检测、断线重连识别。如果用Python写，selectors或者asyncio是常见选择；生产环境很多人直接用Netty、Vert.x这类框架，或者干脆用EMQX这类MQTT Broker走MQTT over TCP，把连接管理交给专业组件，自己只处理消息解析。

2.3 TCP方案的硬成本：连接资源与心跳保活

TCP方案最大的隐性成本在于连接管理。一台机房监控服务器同时接入几百个传感器很常见，意味着要维护几百个长连接。每个连接都要占文件描述符、内核内存，还要靠应用层心跳来判断连接是否还活着。

温湿度采集的场景中，传感器可能几秒到几分钟才发一条数据。TCP长连接如果太久没有数据传输，中间的网络设备（比如NAT网关、防火墙）可能会把空闲连接清掉。所以你必须设计心跳机制：传感器定期发一个特殊的心跳包，服务器端定期检查“多久没收到某台设备的数据就判定离线”。这个心跳周期的设置，也是一个经验活——设得太短浪费带宽和电量，设得太长又无法及时发现设备掉线。机房场景一般建议30到60秒发一次心跳。

还有一个容易被忽略的问题：TCP的队头阻塞。如果某条连接的网络质量差，一个包丢了要等重传，后续的数据都得排队。温湿度数据本身量小，这个问题影响不大，但在多传感器共用同一链路的场景下还是会有连带效应。

小结：TCP方案适合数据必须逐条确认、不允许丢失的场景，或者传感器数量不多（百台以内）、接收端是自己开发的采集服务。如果传感器直接对接动环主机，选TCP最省心。

3. UDP轻量上报方案：资源占用少，但别拿它当TCP用

UDP经常被误解为“不可靠的协议”，实际上在温湿度采集这种小数据量、低频率的场景，UDP的可靠性完全可以通过应用层手段补足，且整体性价比往往比TCP更高。

3.1 UDP的“轻”体现在哪里

UDP是面向无连接的传输层协议，发送数据前不需要握手，发完就完事。它的报文头只有8个字节，没有序列号、确认号、窗口等一堆字段，内核协议栈的处理开销远小于TCP。

这个“轻”在嵌入式传感器上有直观体现：很多以太网温湿度传感器用的是低成本的MCU，片上资源有限。跑TCP协议栈要维护连接状态、重传定时器、拥塞控制状态机，内存和CPU都吃紧；而UDP协议栈几乎就是个“发送函数”，MCU的压力小一个数量级。同理，不具备网口的传感器通过串口接一个DTU（数据传输单元）上云时，很多DTU也是走UDP转发，原因就是省资源、省流量。

3.2 UDP上报的经典模型与代码示例

UDP温湿度上报的经典模型是“发后不管”：传感器周期性向监控服务器的固定端口（比如9000）发送数据报，服务器只负责收包解析。

import socket, time, json SERVER_IP = "192.168.1.100" SERVER_PORT = 9000 sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) def read_sensor(): # 读取温湿度传感器的实际数值 return {"device_id": "TH-001", "temp": 25.3, "humidity": 45.6} while True: data = json.dumps(read_sensor()) sock.sendto(data.encode("utf-8"), (SERVER_IP, SERVER_PORT)) time.sleep(5) # 每5秒上报一次

服务器端只需要绑定端口，然后循环recvfrom即可。没有连接维护、没有状态管理，多台设备的数据通过源IP和端口就能区分。

3.3 应用层补可靠：UDP不是裸奔

“UDP丢包了怎么办”是所有人都会问的问题。答案是：自己实现应用层可靠性。温湿度采集场景里，常用的补强手段有三板斧：

第一板斧：重复发送。同样一条数据发两遍或三遍，接收端通过序列号去重。由于单包只有几十字节，重复发送对带宽的压力几乎可以忽略。比如5秒上报周期，每条数据连发两次间隔100ms，丢包率就能下降一个数量级。

第二板斧：序号与缺失检测。每条上报数据带一个自增序号，接收端检测到序号跳变就知道中间丢了数据，可以主动向设备发一个补报请求。设备的UDP接收能力不用很强，能收一条几十字节的命令即可。

第三板斧：超时重发。传感器每发一条数据，启动一个定时器，如果2秒内没收到服务器回执，就重发一次。重发三次仍无回执则切换告警状态。

这三个机制加起来，可靠性已经逼近TCP，但实现复杂度远低于维护一个TCP连接。

3.4 UDP场景的注意事项

• 监控服务器和传感器务必在同一个二层网络或用静态路由打通，避免UDP广播被隔离。传感器的目标地址配置为服务器IP，而不是广播地址。
• 如果跨网段传输，要注意防火墙是否放行了对应UDP端口。很多机房安全策略默认拦截未知UDP流量，排查的时候感觉就是“数据发出去了但服务器收不到”。
• 服务器端接收程序要有解包容错能力。UDP没有传输层校验和保障链路质量一说，应用层一定要做数据格式合法性校验，防止脏数据入库。

小结：UDP方案适合传感器数量大、上报频率高、服务器性能和带宽资源敏感的场景。自己开发采集服务时，优先考虑UDP+应用层补可靠，成本和稳定性都能兼顾。

4. SNMP网管兼容方案：不懂也要会配的老三样

前两种方案解决的是“数据怎么到我的程序里”，SNMP解决的是“数据怎么进网管系统”。如果你面对的是一套已经跑了好几年的机房动力环境监控平台，供方大概率只认SNMP。这跟技术先进性无关，纯粹是历史兼容和生态锁定。

4.1 SNMP到底是什么

SNMP（Simple Network Management Protocol，简单网络管理协议）是专门用于IP网络设备管理的应用层协议，运行在UDP的161（Agent端）和162（Trap端）端口之上。它定义了一套标准化的管理信息结构，也就是MIB（Management Information Base），用树形结构组织设备的各类管理对象，每个对象有一个数字形式的OID（Object Identifier，对象标识符）。

一个温湿度传感器嵌入SNMP Agent后，网管系统就可以通过标准的SNMP Get请求读取传感器的温度和湿度值。比如：

• 1.3.6.1.4.1.XXXXX.1.1.0表示温度
• 1.3.6.1.4.1.XXXXX.1.2.0表示湿度

网管平台只需要知道OID就能获取数据。如果传感器还实现了Trap功能，当温度超过告警阈值时，传感器主动向网管的162端口发一个Trap报文，网管就能实时弹告警。

4.2 用起来是什么感觉

假设你手头有一个支持SNMP的温湿度传感器，要验证Agent端是否正常工作，最好的工具是net-snmp提供的命令行工具：

# 读取温度值，参数含义：v2c使用SNMPv2c协议，-c public是共同体名，-t 10是超时时间 snmpget -v 2c -c public -t 10 192.168.1.50 1.3.6.1.4.1.XXXXX.1.1.0

返回结果类似：

SNMPv2-SMI::enterprises.XXXXX.1.1.0 = INTEGER: 253

这里的单位通常是0.1℃，也就是253代表25.3℃。具体单位定义要看厂家的MIB文件。

如果要把告警上送网管，则在网管上配置Trap接收，传感器端开启Trap上报并填上网管IP。由于SNMP使用UDP承载，Trap本身是不可靠的，网管系统一般会结合轮询（Get）和事件（Trap）双通道来保证数据完整。

4.3 SNMP版本怎么选

SNMP有三个主流版本，选型的坑非常多，单独列出来讲：

SNMPv1是1988年的老古董，明文传输，没有真正意义上的安全认证，只靠一个“共同体名”（community string）做身份鉴别。相当于门卫只问你是不是这个小区的人，你随便报个名字就能进。但它的兼容性最好，十年前的老网管平台只认v1。

SNMPv2c在v1的基础上增加了批量获取（GetBulk）、计数器64位扩展等能力，传输效率提升明显，但认证机制仍然只有明文共同体名。目前是机房设备兼容性最好、用得最多的版本。

SNMPv3引入了USM（基于用户的安全模型），支持MD5/SHA认证和DES/AES加密，安全性大幅提升。代价是需要维护用户表、密钥等额外配置，很多嵌入式传感器由于资源限制不太支持，网管平台的配置复杂度也高。

选型建议很直接：内网机房且网管平台够新，优先SNMPv3；需要兼容老旧平台，选SNMPv2c；非不得已不要用v1。至于是否支持SNMPv3，传感器的规格书里一般会写清楚，采购前一定确认。

4.4 嵌入式SNMP移植的成本

如果传感器本身不带SNMP功能，你想自己往嵌入式设备里移植SNMP Agent，这事得提前掂量掂量。最常见的开源方案有：

• net-snmp（旧称uCD-SNMP）：功能完整、生态庞大，支持Agent端和Manager端，官方支持Windows/Linux/BSD等平台。但对资源有限的MCU来说体积偏大，裁剪后也很难跑进200KB以下的Flash。
• Snmpd精简版/轻量SNMP栈：比如用C语言自己实现一个只包含MIB树、Get/Set/Trap处理的最小Agent，或者基于开源协议栈裁剪。
• 商业闭源库：比如EmbeNets等，优点是占用资源可控、提供FAT二进制适配，缺点是收费且出问题不好排查。

我的建议是：除非你是传感器的原厂工程师，否则不要轻易自己移植SNMP Agent。采购传感器时直接选择支持SNMP的型号，比自己折腾划算得多。如果一定要做，优先找基于开源协议栈裁剪过的商业方案，能省去一大波调MIB树和OID注册的坑。

小结：SNMP方案适合对接已有网管平台、远程统一运维的场景。传感器端配置简单，网管侧语义标准化，但要注意安全性和版本兼容。它是设备厂商和网管平台之间的“普通话”，不是你可以绕开的标准。

5. 三种方案横向对比与选型决策

协议选型没有绝对的好坏，只有是否匹配场景。我习惯用一张表把关键维度拉出来对比，这样开会讨论时也能快速对齐：

5.1 从项目角色倒推最优解

选型不要站在“哪个协议好”的角度，要站在“我在这个项目里是谁”的角度：

如果你是传感器采购方，且现场已有成熟动环平台— 直接问平台厂家“你们北向支持哪些协议”，大概率答案是SNMP，可能还有Modbus TCP。这时候别挣扎，直接选支持SNMP的传感器型号。

如果你是自己搭采集系统，且传感器数量少于三百台— 首选TCP。数据完整性和连接管理都有成熟方案，团队里的开发人员不需要太多网络背景就能排查问题。

如果你是自己搭系统，但传感器数量大、分布机房多— 考虑UDP+应用层可靠性设计。省下的连接资源可以给接收服务更多冗余余地，尤其是后面要横向扩容时，UDP方案做负载均衡的难度远低于TCP长连接。

如果你的核心诉求是快速告警而非精确数据— SNMP Trap最合适。温度一超阈值立即上送，网管弹窗、短信通知一链式打通，不用自己造告警引擎。

5.2 组合选型的常规操作

很多实际项目最后是组合方案：传感器走TCP或UDP上报给采集网关，采集网关再转换成SNMP或MQTT接入上一层网管平台。比如你可以用树莓派或者工业边缘网关把本地TCP/UDP数据汇聚，然后通过SNMP Agent把数据喂给上层动环系统。网关相当于一个翻译官，把私有协议翻译成标准协议，两边都不用改。

这种分层设计的好处是隔离变化：传感器换了品牌、换了协议，只要调整网关侧的适配逻辑，上层平台完全不用动。

6. 混合组网实战：一个多机房项目的真实配置示例

理论聊完，上一个实际案例。去年下半年我给一个五机房项目做温湿度采集方案，现场情况是：三个机房用的是不同品牌的以太网传感器，一个机房有独立动环网管，另外两个机房只有自建监控系统。最终落地的方案就是TCP + UDP + SNMP 三种并存。

6.1 设备接入层设计

以其中一个机房为例，现场有42台机柜，每个机柜部署2个温湿度传感器（机柜前门和后门各1个），共84个点位。监控服务器是两台CentOS 7虚拟机，分别部署采集服务和告警服务。

接入层规则是：

• 传感器支持TCP且数量少（小于30台）的机房，直接走TCP上报。
• 传感器数量多且上报频率要求较高的机房（每3秒一条），走UDP上报，应用层做重复发送和序号校验。
• 需要对接动环网管的机房，在网关服务器上部署SNMP Agent，从UDP采集服务里取数并映射成OID，同时配置Trap告警。

6.2 UDP采集服务的核心代码片段

UDP采集服务是整个方案的流量入口。它不关心上游传感器是TCP还是UDP，只负责把数据标准化成统一的JSON结构写入Redis做暂存，再异步落库。

import socket, json, redis UDP_IP = "0.0.0.0" UDP_PORT = 9000 REDIS_MQ = "channel:sensor:raw" r = redis.Redis(host="127.0.0.1", port=6379, db=0) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((UDP_IP, UDP_PORT)) def parse_packet(payload): # 根据传感器厂商协议解析 # 假设格式: "TH-001,253,456" 表示设备ID, 温度(0.1℃), 湿度(0.1%) parts = payload.decode("utf-8").split(",") return { "device_id": parts[0], "temp": int(parts[1]) / 10.0, "humidity": int(parts[2]) / 10.0, "ts": int(time.time()) } while True: data, addr = sock.recvfrom(1024) try: parsed = parse_packet(data) r.publish(REDIS_MQ, json.dumps(parsed)) except Exception as e: # 脏数据兜底，不打崩主流程 print(f"parse error: {e}, raw={data}")

UDP端口只做一次bind，所有传感器的数据都会被打上来源IP（addr[0]），后续按IP反查设备编号即可。

6.3 SNMP网关Agent的OID映射设计

SNMP网关Agent的核心工作是把UDP采集到的温湿度数据挂到自定义的OID树下。我用的思路是给每个传感器分配一个索引号，然后在企业私有OID下动态注册节点：

企业前缀: 1.3.6.1.4.1.9527 (模拟厂商ID) 传感器1: 1.3.6.1.4.1.9527.1.1.1.0 温度 传感器1: 1.3.6.1.4.1.9527.1.2.1.0 湿度 传感器2: 1.3.6.1.4.1.9527.1.1.2.0 温度 传感器2: 1.3.6.1.4.1.9527.1.2.2.0 湿度

网管平台只要通过snmpwalk遍历这个子树就能批量采集所有传感器的数据。

Trap告警的配置需要注意一个细节：Trap消息里必须带上设备标识和当前值，否则网管那边只能看到“某台设备告警了”，还得去翻OID树才能定位是哪个机柜，效率极低。

6.4 这个混合方案的实际效果

运行半年多，日均处理温湿度数据点约160万条，UDP通道的丢包率约为0.02%，全部来自网络割接瞬时抖动，重复发送机制有效兜底。TCP通道由于传感器数量少，连接稳定，未出现卡死或串包问题。SNMP侧由网管平台每分钟轮询一次，数据量级完全无压力。

方案的核心好处是：每个机房内部的传感器协议，完全取决于那个机房已有的硬件条件和人员能力，不强行统一，但所有数据最终都汇聚进了同一套模型。

7. 常见问题与排查技巧实录

协议选型定了，真正的战斗才开始。下面这些坑都是我实际踩过的，任何一个都能让你折腾一整天。

7.1 TCP连接频繁断开，重连风暴打垮服务器

现象：传感器上报几分钟后连接断开，过几秒重连，服务器上大量TIME_WAIT连接堆积，偶尔出现“Too many open files”报错。

排查过程：先看传感器日志，发现是服务端主动关闭了连接。再看服务端程序日志，发现设了60秒无数据超时断连，而传感器的心跳间隔是90秒，正好超过阈值被判定为死连接。

解决方案：把服务端超时时间调整为心跳间隔的3倍以上，比如心跳60秒，服务端150秒无数据再断开。同时传感器端增加断线退避策略，避免重连风暴。

提示：TCP方式排查的第一件事永远是“两边的超时参数是不是匹配”，而不是“代码有没有bug”。

7.2 UDP数据丢失严重，但内网带宽很充足

现象：传感器上报500条，服务端只收到480条左右，丢包率4%，远超预期。

排查过程：用tcpdump在传感器侧和服务端分别抓包，发现数据确实出网卡了，服务端也收到了，但应用层日志缺数据。进一步检查发现接收程序用了单线程同步阻塞处理，每条数据都要经过一次Redis写入，遇到Redis瞬时抖动时处理不过来，内核缓冲区溢出丢包。

解决方案：接收端改为多线程或使用消息队列异步处理，把UDP socket的接收缓冲区调大（setsockopt(SO_RCVBUF)）。改完后丢包率降到万分之三以下。

提示：UDP丢包不一定发生在网络上，更常见的是应用层消费速度跟不上内核收包速度。

7.3 SNMP轮询超时，但snmpget能通

现象：命令行snmpget能拿到数据，网管平台配置了同一组OID却频繁超时。

排查过程：用Wireshark抓包对比两种访问的区别，发现网管平台的轮询是按批次的，使用GetBulk批量读取，而传感器Agent对GetBulk的支持不完整，导致批量请求超时。

解决方案：在网管侧把读取方式改成单OID轮询（Get），数据量小所以性能差异可忽略；同时在传感器侧检查是否有“最大可并发生成OID数量”的参数，适当调低。

7.4 传感器支持TCP和UDP，但客服也说不清用哪个

现象：采购前问厂家技术支持“推荐用TCP还是UDP”，对方支支吾吾说不清楚。

应对思路：这种情况下，优先看设备有没有明确标注“支持设备主动上报”还是“需要配置接收服务器”。如果设备支持主动上报且频率可调，选UDP大概率不会错；如果设备需要接收端的应答才继续上报，那么只能选TCP。

提示：买传感器时让厂家提供“协议对接文档”，里面应有报文格式说明和示例。文档里没有写清楚心跳、重传越界策略的，默认按最保守的方式做。

8. 选型落地后的几点补充建议

协议定下来只是开始，后面这些事不做，方案的上限也发挥不出来。

时间同步是隐藏的刚需。温湿度数据的分析价值很大程度依赖时间线的准确性。如果传感器的时间不准，上报数据再可靠也无意义。建议在采集服务端做时间归一化：所有数据以服务端收到时间为准，或者至少同网段部署NTP服务让所有设备校时。

数据质量监控比告警本身更重要。我见过太多系统告警配置得很丰富，但数据曲线里全是平台故障期的空白。建议给每条数据打质量标记，比如“连续5个周期无数据”就自动生成一条数据异常事件，这比温度告警更能反映机房真实状况。

传感器掉电解锁是个大坑。机房机柜的PDU断电后，传感器如果没接UPS，重新上电后大概率需要重新初始化网络配置。选择支持DHCP+MAC绑定的型号，或者提前在交换机上做端口隔离和IP/MAC绑定，能省下大量远程重启的运维量。

9. 写在最后的个人经验

这几年的项目做下来，我个人在温湿度采集协议上的选择标准一直在简化，现在基本是三条：

自己建平台、传感器在三百台以内，直接用TCP，调试和排障最轻松；传感器上到千台级，改用UDP并补上应用层可靠性设计；要进网管系统，SNMP是唯一不用求人的路。

所谓的“谁该上桌”，答案从来不是某个协议碾压另外两个，而是你的现场条件适合请谁吃饭。TCP是自带酒水的大餐，适合重要客人；UDP是快进快出的自助餐，高效但不讲究排场；SNMP是所有人都会说两句的普通话，适合跨部门沟通。想清楚自己家底和客人需求，这顿饭就点得明白。

最后再分享一个很实用的技巧：新传感器到货后，别急着往机房里装，先在办公桌上用一条网线接电脑，把三种协议挨个试一遍。记录下每种模式下设备上线时间、上报稳定性和断网恢复时间。这份测试记录会是你后续运维排障时最趁手的参考基准。我每批传感器都会做这个测试，投入不过半天，省下的排查时间远超这个数。