做数据大屏这行最怕听到老板嘴里蹦出一句这个屏要实时订单一下来就得刷出来。说得轻巧。等订单量真的上来在场的人全都开始冒汗。我参与过一个零售业的数据大屏项目高峰期在线连接数逼近百万级老板要求新订单必须在1秒内出现在大屏上。最开始用的HTTP轮询一秒刷一次十几万连接直接把我负责的网关打挂。后来整个方案迁移到WebSocket把连接方式、订阅模型、推送策略重新拆了一遍才算真正把秒级这两个字落地。这篇东西我不会只丢一套架构图给你而是把从需求拆解、容量估算、架构分层、核心代码逻辑到压测踩坑、线上事故复盘这一整套思考过程完整记录下来。适合正在做订单实时大屏、监控看板、运营指挥中心这类项目的团队参考也适合那些想搞清楚WebSocket海量连接到底怎么设计的人。1. 先把秒级刷新翻译成技术指标延迟、吞吐与连接数的三角关系1.1 从老板一句话到可验证的SLA每次听到秒级刷新这四个字我都会先干一件事把它变成一堆可以验证的数字而不是一个模糊的感觉。如果方案做完没办法用监控数据跟老板对账那后面出问题的时候大家就会开始互相甩锅。对典型的订单大屏来说我会把需求拆成三个可衡量的指标端到端延迟从订单入库到大屏渲染出新数据端到端延迟要控制在1秒以内。考虑到网络、前端渲染的时间服务端推送的P95延迟最好做到200毫秒以内否则前端一卡整个屏看起来就像死掉了一样。吞吐量高峰时每分钟产生多少订单、每秒产生多少订单事件。假设峰值每秒产生5万订单而一块大屏通常只需要看全量订单的一部分那推送系统的有效吞吐就要按订单事件数 × 平均订阅数来算。连接规模同时有多少客户端连着这个推送服务。大屏只是展示端但背后可能还有手机端、投屏端、指挥中心的多块屏幕连接数很容易被低估。我手机上一直存着这张表每次需求会都直接拿出来对着填指标单位数值在线连接数个10万100万消息峰值速率条/秒1万10万平均消息大小KB12 KB端到端延迟要求秒≤ 1秒P95推送延迟毫秒≤ 300毫秒一旦这些数字填完你就知道秒级刷新到底是个什么量级的项目了。如果月销百万单的公司说订单要实时刷新那可能只有每秒几十条消息单体服务加个轮询就能搞定。但如果是头部电商或大型连锁千万级日订单峰值每秒几千上万笔那必须从架构层面走WebSocket别抱着轮询不放。1.2 轮询方案为什么先被枪毙一个小学生都能算的账先说个很简单但很多人懒得算的账。假设你有10万个客户端要求秒级刷新用HTTP轮询客户端每隔1秒请求一次。那就是每秒10万次HTTP请求。哪怕每次请求只有几十毫秒的处理时间这10万QPS也会把你的网关、数据库、内网带宽全部压满。更致命的是绝大多数请求拿到的响应都是没有新数据——完全是在用资源换延迟。你可能觉得那把轮询间隔改长点比如3秒或5秒不就行了吗问题是你定5秒老板看到的屏就永远比真实业务慢5秒。大屏这玩意儿老板坐在那里盯着看每一秒的延迟都是能感受到的。再说了就算把轮询间隔放到5秒10万连接照样是2万QPS的空转请求。长轮询也一样虽然能减少一部分空响应但每个长轮询本质上就是挂着一个HTTP连接不放连接一多客户端和服务端的连接管理成本一样爆炸。而且HTTP/1.1的长轮询还有队头阻塞问题多个请求共用一条连接时一个请求挂住后面全堵住。WebSocket的本质优势在于它是服务端推送模型连接建立后没有新消息时连接是安静的不产生任何请求开销。有新订单了服务端主动把数据推给大屏。从复杂度来说推送的开销只跟消息数量 订阅者数量相关跟轮询频率无关。我经常用一句话跟同事解释轮询是在用请求的频率换延迟WebSocket是在用连接的数量换实时性。大屏这类场景连接数虽然多但连接本身是低频活动的WebSocket天然适配。1.3 连接数不是免费的估算单机承载成本很多人一听百万并发WebSocket第一反应是上K8s扩容就行。没那么简单。每个连接都在吃你的内存和句柄。我按单个连接做一个保守估算内核TCP缓冲区读写两端加起来大约16 KB32 KB用户态连接对象包含读缓冲、写缓冲、订阅上下文、鉴权信息大约20 KB50 KB底层事件循环或协程调度器的开销每连接大约0.5 KB2 KB所以一个连接的实际内存占用大概在40 KB80 KB之间。取中间值50 KB10万连接就是5 GB内存。100万连接光是连接本身就要50 GB内存。这不是一台机器能扛下来的必然是多节点水平扩展。但水平扩展不是加机器就行你要解决连接落到哪台机器以及消息要找到对应的连接这两个核心问题这就引出了后面要讲的架构分层。2. 架构分层不要一上来就写推送循环2.1 四层职责划分很多人在扣代码之前脑子里只有一个画面客户端连上WebSocket服务服务端收到订单就遍历所有连接send一遍。这个画面放到小规模场景没问题但一旦连接数上了规模你就会发现三个问题订单业务逻辑和推送逻辑耦合在一起改一个字段就要动推送代码。连接状态和业务状态混在一起网关重启一次所有客户端重新连接直接冲垮后端。每个推送节点只知道自己手里那搓连接全局的订阅关系根本没法维护。我最终把系统拆成四层每一层的边界很清楚层级职责关键点接入层连接网关维护WebSocket连接、心跳、鉴权、消息收发追求连接密度尽量轻量路由层订阅关系维护客户端订阅了哪些通道将消息路由到对应网关节点追求一致性可以弱化实时性业务层事件源接收订单变更、库存变动等业务事件不关心推送细节存储层保存订单、订阅关系备份、推送状态需要可追溯、可重放核心思路一句话概括接入层管连接路由层管订阅业务层管事件存储层管账本。每一层只做自己那点事互相之间靠消息队列和接口解耦。2.2 连接网关为什么必须无状态网关节点最忌讳的就是在本地保存这个用户属于这个网关、那个门店属于那个网关之类的强状态。一旦你做了这件事网关一挂业务就得等它恢复不然消息根本不知道往哪儿送。我在设计时把网关做成无状态节点所有会话信息session全部上抛到路由层。网关本地只保留一种临时状态当前进程里的活跃连接对象。客户端重连的时候负载均衡可以把它分到任何一个网关节点网关从路由层拉回这个连接的订阅关系马上就能恢复推送。这就是大厂常说的状态外置。它牺牲了一点推送路径上的一次远程查询但换来了整个集群的可替换性和高可用。2.3 从订单到屏幕的完整数据链路为了让你对整体架构有画面感我写一下一单成交后的完整链路订单服务写入订单库同时发出一条订单已创建的业务事件到消息队列。推送服务的消费进程拿到事件解析出事件类型、门店ID、区域ID、订单金额等关键字段。推送服务调用路由层的订阅查询接口找出所有订阅了该门店或该区域通道的客户端连接列表。路由层返回一批网关节点地址和对应的连接ID推送服务把消息投递给这些网关节点。网关节点在本地找到对应的连接对象通过WebSocket把消息发给大屏前端。前端收到消息更新看板上的订单数、销售额等指标配合动画效果展示。这条链路看起来长但每跳都是内存或队列操作延迟能控制在几十毫秒。这也是为什么前面说P95 300毫秒是合理的——你的时间是花在跨节点投递上的。3. 订阅关系与连接状态管理百万并发的第一个真实瓶颈3.1 连接Session该放哪本地内存、集中存储还是混合方案先说结论高并发大屏场景我推荐本地内存为主 Redis兜底的混合方案而不是一股脑全放Redis。如果所有连接状态都放Redis那么每推送一条消息都要查一次Redis才能找到目标连接。消息峰值每秒5万条每条消息查一次Redis哪怕Redis再快也会成为瓶颈。而且极端情况下Redis抖动一下整个推送链路全堵住。我的做法是网关本地维护一份连接ID到Session对象的内存映射这就是快速路径。网关定期把自己手里的连接清单上报给路由层路由层把整体连接拓扑写到Redis。当客户端断线重连、被负载均衡切换到新节点时新节点从Redis拉取该客户端的订阅关系重建session。这样做的结果是正常推送路径走本地内存快只有连接迁移和异常恢复路径走Redis慢而稳定。两条路径分离各得其所。3.2 Channel模型设计永远不要给所有客户端广播在订单大屏的场景里最该避免的一个设计就是全量广播。什么意思就是不管你是哪个门店的屏服务端发消息都给所有人推一份。全量广播一时爽连接数一多就火葬场。你想一想如果同时在线10万块屏每块屏都要接收每秒5万条全量订单那每条消息要被复制10万份这个推送量就是每秒50亿条消息分发没有任何单集群扛得住。合理的做法是引入Channel通道模型按业务维度和地理维度拆分每个门店一个Channel门店自己的大屏只订阅本门店Channel。每个区域一个Channel区域总览大屏订阅区域下面的所有子门店Channel。一个全局Channel只给最高层的总览大屏使用。推送服务在处理订单事件时解析出该订单属于哪个门店、哪个区域精确匹配Channel。比如订单落在A门店那就只往A门店Channel投递全链路只有那几块屏收到消息。这样即使总订单量很大单条消息的扩散系数被压得很低。3.3 生命周期管理与心跳别被反向代理的沉默杀掉WebSocket连接建立后真正折磨人的是保活和超时。绝大多数线上WebSocket连接前面都隔着一层负载均衡或反向代理。代理往往有自己的空闲超时配置比如闲置60秒就断掉连接。如果客户端只是偶尔收消息你会看到大屏时不时断线重连但业务日志查不出任何异常。我在项目里直接定了两条硬性规则客户端每30秒发送一次心跳ping服务端应答pong。服务端如果90秒内没收到任何数据帧判定连接死掉主动断开并清理会话。这套参数不是随便定的。心跳间隔必须小于代理的空闲超时我见过不少代理把空闲超时设在60秒左右但又不能太频繁不然10万连接每分钟产生20万个ping包也是在烧带宽和CPU。30秒一次90秒判定算下来是很多团队验证过的平衡点。同时服务端必须对超过阈值的静默连接做主动清除。不然你以为连接还在但客户端已经掉线五分钟消息全堵在TCP缓冲区里内存越涨越高。4. 推送实现批量合并、背压控制与序列化选型4.1 单条推 vs 批量推不一样的CPU账单最开始的版本我写得很爽业务层来一条消息网关就发送一条代码简单逻辑清晰。等连接数上了5万问题立刻暴露。每条WebSocket消息都是一次系统调用级别的网络写入。如果一秒来5万条消息网关就要执行5万次写操作。而如果每条消息还要实时遍历订阅者那后面的锁竞争、上下文切换会让你痛不欲生。后来我引入了一个合并窗口batch window机制思想就是把一段时间内的消息攒起来一次性批量发出去。大致逻辑是// batchWorker 负责在窗口内累积消息并批量发送 func (b *BatchWorker) Run() { batch : make([]*Message, 0, 64) timer : time.NewTimer(b.window) // 通常设10ms defer timer.Stop() for { select { case msg : -b.ch: batch append(batch, msg) if len(batch) b.maxBatchSize { b.flush(batch) batch batch[:0] timer.Reset(b.window) } case -timer.C: if len(batch) 0 { b.flush(batch) batch batch[:0] } timer.Reset(b.window) } } }10毫秒的窗口意味着消息最多延迟10毫秒但CPU消耗大幅下降。实测下来同样的机器配置开启批量合并后单网关支持的推送吞吐直接翻了一倍多。对大屏而言10毫秒的延迟完全无感。4.2 背压控制当消费者跟不上时怎么办WebSocket推送本质是流式管道但客户端不一定每时每刻都跟得上。某块大屏的浏览器标签页被切到后台页面卡顿或者网络抖动都会导致客户端处理不过来。这时候服务端如果一味地往TCP缓冲区里塞数据只会造成内存持续上涨最后整个网关被拖死。我处理背压的优先级是这样的为每条连接设置一个有界发送队列默认100条消息。如果队列满了先丢弃低优先级消息比如旧版本的订单状态。连续丢弃超过阈值直接断开这个客户端连接让它重连后再走增量同步。丢掉消息听着不优雅但大屏场景有一个天然优势前端显示的是最新状态而不是完整日志。如果有一条旧订单状态被丢了下一秒新状态到了大屏依然正确只是少了一个中间态动画。死死揪着每一条消息不放反而会把整条推送链路堵死。4.3 序列化与压缩小消息别走歪路很多团队选序列化方案喜欢一刀切上二进制协议说是为了性能。但这属于典型的过度设计。我实测过几种方案的差异方案平均消息体大小编解码CPU开销结论原生JSON大约2KB中研发友好排障直观精简JSON字段缩写中约1KB中低推荐Protobuf等二进制小约300B低极致性能但排障痛苦JSON压缩取决于压缩率高小消息不划算结论是什么消息体只有几百字节到几KB的订单事件完全不需要压缩。压缩带来的CPU开销可能比省下的那点带宽成本还高。真正要压的是读放大和连接数而不是这几个字节。开压缩只有一种情况值得做单条消息大到几十KB以上比如要推某张图片或大段报表。所以我对大屏推送的建议就是JSON可以接受能把字段名缩得短一点就更好别在序列化上纠结。整个系统的瓶颈通常在网络帧数和内存占用上而不是负载大小。5. 压测与内核调优把单机承载顶上去5.1 压测不只是测QPS代理连接压测才是大头很多团队用JMeter什么的压WebSocket一压就是几十个线程跑请求测出来的其实是吞吐不是连接密度。大屏场景恰恰相反最大的压力不是消息量而是海量长连接本身。为了模拟真实场景我写了一个专门的大规模连接压测脚本逻辑很简单在一个压测客户端进程里创建数千个虚拟连接。通过TCP直连网关发起WebSocket握手。握手完成后连接保持不发业务消息模拟正常挂机的客户端。逐步增加虚拟连接观察网关的内存、CPU和句柄数变化。这套压测的目标不是打出多高的吞吐而是验证一个问题当5万连接同时挂在一个网关节点上各类资源曲线是否平稳。压测过程一般分四步走从小规模2万连接开始确认基础资源占用正常。每增加1万连接记录一次内存、CPU、句柄使用情况。观察是否存在内存突增、句柄泄漏、延迟劣化。达到目标连接数后持续压测24小时验证稳定性而不是瞬时表现。5.2 操作系统参数这几个值不改连接数根本涨不上去有次我印象特别深刻。网关代码写得很好压测跑到3万连接就再也上不去了每增加一千连接整体CPU就开始剧烈波动。查了很久最后发现是操作系统文件描述符不够。Linux下一个进程能打开的句柄数默认是1024哪怕你改到了65535对10万连接来说一样不够。以下是几个高频参数做高连接数服务必须提前调参数建议值作用fs.file-max2000000系统级总文件描述符数ulimit -n1048576单进程文件描述符限制net.core.somaxconn65535全连接队列长度防握手丢失net.ipv4.ip_local_port_range1024 65535本地端口范围影响出站连接net.ipv4.tcp_tw_reuse1端口快速回收减少TIME_WAIT这些参数名你在任何一本Linux调优书里都能找到但真正踩过坑的人才明白它们的价值。特别是net.core.somaxconn如果设置太小高并发握手时客户端会大量超时表现为连接建立缓慢但看服务端日志一切正常。5.3 一次压测暴露的CPU瓶颈系统调用与锁有次压测到8万连接时发现CPU的sys占用飙到40%以上user占用反而很低。这说明服务端的大量时间耗在系统调用和内核态切换上而不是业务逻辑上。排查下来有三个躲避不开的坑每个连接独立epoll注册事件循环过于分散导致系统调用次数爆炸。哈希表用了全局锁所有连接共用一个并发写入时锁竞争严重。每个连接都单独分配缓冲区GC和内存分配压力巨大。解法也比较成熟用多Reactor模型或协程调度器把事件处理收敛到有限的线程或协程上。连接级的锁粒度尽量细化比如按分段加锁。复用缓冲区消息对象从消息池里取用完放回去。压测这个环节千万不能省也别拿几万连接数就当作生产环境。大屏流量是有峰值的你必须在峰值至少两倍连接数下验证过稳定性上线心里才有底。6. 上线之后断线风暴与消息乱序的复盘6.1 一次发布引发的全员重连事故这个坑是我最想分享的因为它几乎杀死了我们整个大屏系统。事情是这样的某天凌晨我要给网关集群升级配置因为当时赶进度图省事直接对网关节点滚动重启。结果重启一个节点的时候上面挂着的5万个客户端瞬间断开然后客户端按固定的3秒重连间隔疯狂地向负载均衡发起重连。问题在于那批大屏分布在不同的网络环境里重连请求几乎是同时到来的一瞬间把负载均衡和网关的握手线程全部打满进而导致其他节点也开始拒绝服务。其他节点上的客户端一看连不上也开始重连。就这样一个节点的重启引发了全集群的断线重连风暴。处理这个问题的标准手段是指数退避 随机抖动。具体到客户端逻辑就是第一次重连等1秒失败后等2秒再失败等4秒、8秒、16秒。每次重连时间加上一个随机值比如随机03秒防止所有客户端同时发起连接。服务端发布时也要控制节奏一次只重启一个节点并且等一批新连接稳定后再动下一个。这套组合拳打完后续再也没出现过一次发布导致的全员重连。现在我做任何跟大屏相关的多客户端系统上线发布流程里都强制要求检查两点客户端有没有退避机制、发布有没有分批节奏。这两个没确认代码写得再好我也不敢发。6.2 消息乱序与重复业务层怎么兜底WebSocket本身是保序的但你的推送链路中间只要有消息队列、多副本消费、网络重试乱序和重复就是必然的。举个例子。两个订单事件分别是订单状态已支付和已发货。如果推送服务在处理时发生重试已支付比已发货晚到大屏上就会出现订单状态倒退很尴尬。我的兜底方案是在业务事件里加入版本号和事件时间戳{ event_id: order_created_20250101103001_12345, sequence: 1024, order_id: ORD123456, status: PAID, timestamp: 1735713001000 }前端收到消息后先比较sequence比本地小或相等就直接丢弃。如果重复消息靠event_id做幂等前端只处理一次。这套方案没有完全依赖传输层保证而是把最终一致性交给业务层自己处理。消息可能重复但最终大屏上的状态一定是最新且正确的。对秒级刷新的需求来说足够。6.3 大屏系统的监控指标要盯什么做完了功能和压测最后必须把监控体系立起来。我之前就有一次教训系统看起来运行正常但用户反馈大屏偶尔卡顿排查了一下午才发现是重连率在缓慢攀升只是没人看这个指标。现在我的大屏系统监控面板最少包含这几个指标当前连接数以及每节点分布是否均匀。连接建立速率每秒新建连接数出现突增说明可能有重连风暴。重连率这个指标是健康度的晴雨表。消息推送延迟统计P50、P95、P99。推送失败率和被背压丢弃的消息数。所有指标都要按网关节点维度拆分。别只看聚合值一个节点出问题聚合值可能只波动一点点拆分到节点才看得出是哪台机器在裸奔。7. 如果让我重来我会先做这三件事第一在写任何网关代码之前先把压测脚本写好。我先跑了压测脚本原来对连接密度和内存的概念只是纸面的真正压测下去以后才会对系统设计有直觉。第二先把订阅关系模型画清楚再动业务代码。我见过不少团队代码里写着写着就冒出一个sendAll()全量广播原因就是后端方便。这个口子一开连接数一多救都没法救。订阅模型是你的推送系统的心脏一定要在最开始就明确Channel粒度后面不要太随意地加全量通道。第三监控和告警上线后必须有人管。你不理监控系统出事的时候就不会给你任何准备时间。最后还是忍不住提一句大屏项目表面上拼的是前端动效和UI炫不炫实际上拼的是后端能不能在百万连接下把一条消息在几百毫秒内送到该去的地方。WebSocket只是入口真正的功夫全在连接管理、订阅路由和背压控制这些听起来不性感的地方。希望这套方案的拆解能让你少走几个月的弯路。