去年冬天，数据上传我在一个做视频监控的服务客户那里蹲了三天。他们的数据上传服务器每天凌晨两点准时卡死，运维换了三拨人也没找到原因。服务最后发现是数据上传数据上传的并发策略有问题——三千多个摄像头在整点同时往一台服务器推流，像早高峰地铁口突然涌出几千人，服务谁也进不去。数据上传

数据上传服务器这件事，服务表面看就是数据上传“客户端把数据发过来，服务器收下存好”。服务真做起来，数据上传坑全在细节里。服务

先说什么叫“上传”。数据上传HTTP 表单那种点一下按钮传个文件的服务场景，和物联网设备每隔几秒上报一次温度，数据上传完全是两码事。前者可以容忍几秒延迟，后者要是丢了数据，可能意味着一条产线的良品率统计全乱套。我见过一个做智能水表的团队，他们最初用普通的 REST API 接收数据，每块表每五分钟发一次 JSON。结果小区里两千块表，每天产生将近六十万次请求。数据库连接池直接被打满，运维半夜爬起来重启服务成了常态。

后来他们换了个思路。设备端不再直连数据库，而是先把数据丢进一个消息队列——比如 Kafka 或者 RabbitMQ。服务器只负责从队列里消费，批量写入。这就好比原来每个快递员都直接冲进仓库找货架，现在改成统一卸到分拣中心，仓库管理员按批次处理。上传的“服务器”其实变成了两层：接入层负责收，存储层负责落盘。压力被摊开了。

但队列也不是万能药。有一次我帮一个做车联网的朋友排查问题，他们的 T-Box 上传频率很高，每秒钟几十条 GPS 轨迹。Kafka 集群看着吞吐量没问题，可消费端总是延迟。查到最后发现是每条消息都带了一个巨大的 Base64 图片字段——车辆抓拍的小图。每条消息将近 200KB，网络带宽先扛不住了。解决方案很土：图片走单独的对象存储通道，消息队列里只留 URL。上传服务器的设计，往往不是服务器本身的问题，而是数据格式和通道划分的问题。

还有一个容易被忽略的点：断点续传和幂等性。用户上传一个 2GB 的视频文件，传到 99% 的时候网断了。重新传，服务器是覆盖还是追加？如果客户端没做分片，服务器没做校验，最后可能得到一个损坏的文件。我见过一个网盘团队的做法——客户端把文件切成 5MB 的块，每块带一个 MD5。服务器收到块先存临时目录，全部收齐再合并。如果某个块传了两次，MD5 一样就直接丢弃。这叫幂等，意思是“你发一次和发一百次，结果都一样”。听起来简单，但很多自研的上传服务压根没考虑这点。

最后说个反直觉的观察。很多人以为上传服务器的瓶颈在磁盘 I/O 或者 CPU，实际上大部分中小规模场景下，瓶颈在文件描述符和网络连接数。Linux 默认单进程只能打开 1024 个文件，你一万个设备同时连上来，还没开始收数据，accept 队列就满了。调内核参数、用 epoll、上多进程，这些才是日常。

数据上传服务器没什么神秘。它就是一个尽职的收件员，关键是想清楚：谁在发、发多快、发多大、断了怎么办。把这四个问题回答好，剩下的就是调参数和加机器的事了。