千级移动端变更上报SpringBoot后端的最优方案选型

直接选方案1：客户端发送简单HTTP请求完成上报，另外两个方案在你这个场景下纯属于过度设计，完全没必要。

你总共就1000个移动端客户端，每5分钟同步一次，算下来服务端平均每秒才接3.3个请求。这个量级的请求，你哪怕拿个2核4G的服务器跑SpringBoot默认配置，CPU使用率都不会超过5%，根本轮不到谈什么资源开销瓶颈。
给你掰扯清楚你关心的两类开销的实际差异：

• 所谓「大量短请求的开销」：现在HTTP/1.1默认开启连接复用，移动端常用的OkHttp、Retrofit这类库默认都会复用TCP连接，根本不是每次请求都重新做三次握手、四次挥手，每次请求的额外消耗只有少量HTTP头的解析处理。对现在的服务器来说，每秒扛几千个这类简单上报请求都毫无压力，你这3点几的QPS连性能零头都用不到。
• 所谓「维持长连接的开销」：不管是WebSocket还是长轮询，服务端都要为每个客户端维护独立的连接上下文、定期做心跳探活，还要处理移动端常见的网络切换（切WiFi、进电梯断网、弱网超时）带来的连接重建、状态同步问题。哪怕你用异步非阻塞框架把内存压到最低，1000个长连接带来的运维成本、代码复杂度，都比跑普通HTTP接口高好几个量级。

• 普通HTTP请求上报：完美匹配你这种客户端定时主动上报、服务端不需要主动实时推送消息的场景。实现成本极低，SpringBoot写个POST接口加个参数校验、持久化逻辑就完事，客户端侧的超时、重试逻辑都是HTTP库自带的，服务端不用存任何连接状态，后面要扩容直接加机器就行，前面挂反向代理也不用做特殊配置。
• WebSocket：只适合服务端需要毫秒级主动向客户端推消息的场景，比如即时聊天、实时监控大屏推送、在线协同这类业务。你这5分钟才同步一次数据，用WebSocket纯属高射炮打蚊子，平白多写一堆连接保活、断线重连、消息幂等的逻辑，移动端后台杀进程之后的连接恢复问题还够你调好久。
• 长轮询：本质是没法用WebSocket的时候，在HTTP协议上模拟服务端主动推送的折中方案，开销比普通HTTP高很多，适合网页端那种没法稳定持WebSocket连接、又需要服务端及时推消息的场景。你这客户端主动定时上报的场景用长轮询，连接长时间占着不说，每次轮询超时重连的消耗比直接发个上报请求还大，纯纯给自己增加工作量。

别死记八股文里说长连接性能好、短连接开销大，结论都是有前提的：只有当客户端量级到十万以上、单客户端请求频率到秒级的时候，你才需要去权衡短请求的握手开销和长连接的维护成本。你现在这个业务量级，怎么实现简单、怎么维护方便就怎么来，提前做的所谓“性能优化”全是无用功。
唯一要注意的点就是给上报接口做好幂等校验，避免客户端网络重试产生重复数据就行，其他的性能优化等真的遇到瓶颈了再加都完全来得及。

内容的提问来源于stack exchange，提问作者Anuar Aidynbayev