无人零售云值守：一个坐席管 30 家店，切流与并发怎么设计

一人管 30 家店，真正的约束不是延迟，是预警之后切到那一路的速度。容量要按同时观看路数算，不是按接入门店总数算。

“30 家门店配 3 个坐席。”这是无人零售云值守项目立项时最常写下的目标。上线之后，坐席反馈最多的一句通常不是“画面卡”，而是“看不过来”。

团队于是回去压延迟，把端到端从 1 秒压到 400 毫秒，坐席还是看不过来。因为决定坐席效率的从来不是延迟，是切到该看的那一路要花多久。

一、瓶颈不在延迟，在切流效率

延迟当然重要，但在看画面这个动作上它解决得比较充分：主流 RTC 平台的实时音视频延迟在 200 毫秒量级，而单向看画面对延迟的宽容度很宽，500 毫秒到 1 秒都不会让人觉得不对劲。

零售场景真正稀缺的是坐席的注意力。门店绝大多数时间段是正常的，异常事件稀疏且集中在少数时段。“同时看 30 路”不是真实需求，真实需求是：任意一家店触发预警后，坐席能尽快看到那一家，并清楚自己在看哪一家。

翻译成工程指标，架构目标应该是“预警到画面出现的响应时间”，而不是“同时并发观看的路数”。

二、“一人管 30 家店”拆成三个约束

1. 单路画面的解码开销。 每个正在播放的视频流都要占一份解码与渲染资源。同样是一路，1080p 25 帧和 720p 15 帧的开销差距很大。所以“能看多少路”首先取决于每一路开多大，而不是网络有多快。
2. 多路同时解码的客户端上限。 上限是乘出来的：路数乘以单路分辨率再乘以单路帧率。它在浏览器里尤其硬，Web 端的解码要和页面渲染争抢同一份资源，撑不住时不是某一格变卡，而是整页掉帧。具体位置必须在目标机型上实测。
3. 坐席在门店之间切换的注意力成本。 人从上一格的语义里跳出来，再重新建立对当前画面的判断，消耗的是人的反应时间，量级远大于技术侧的首帧时间。它是三个约束里最大的一项。

前两个约束都有工程手段，第三个没有，唯一的办法是减少切换次数。

三、按“同时观看路数”分档，不是按“接入总路数”分档

一家门店每天真正需要人来判断的时间可能只有几分钟，剩下的时间只需要证明“它一切正常”。而证明“正常”不需要实时视频流：主流 RTC 平台的云端截图默认每 10 秒对房间内的所有流截一次图，输出 JPG。把几十家店的截图排在墙上，坐席扫一眼就知道哪家不对劲，几乎不占解码资源。

另外注意，单流录制模式下无法边录制边截图，混流录制模式下可以同时截图和录制，既要留证又要巡检的项目应当按混流模式建录制任务。

从 A 到 D，成本不是线性上升的。对多数无人零售项目，C 档是投入产出比更合理的落点：常态几乎不解码，事件驱动时才拉起实时流。D 档只在大屏集中监控这类场景里成立，瓶颈通常不是设备，是人。

四、把单店的多路压成一路

零售门店通常不止一个摄像头：收银台、货架通道、后仓、门口。坐席要在一家店里同时看四路，前面的解码约束会立刻收紧。

混流是一条现成的路。以行业主流方案为例，即构（ZEGO）这类平台的混流在服务端执行，它的实际动作在服务端完成，“没有浏览器性能上的限制”，且各流之间延迟低、音画同步。把一家店的四路合成一路，坐席端需要解码的路数就从 4 降到 1。

混流不是免费的默认项：需要单独开通，一个任务最多输出 4 路不同分辨率的视频流，且目前仅支持服务端混流；自动混流任务在输入流持续 90 秒不存在后会自动结束，没有主动结束会影响计费。

要记住混流压的是什么。它压的是坐席端的解码路数，压不掉门店侧的摄像头数量与上行带宽，四路仍然要各自上行。

五、门店侧：带宽波动不该由坐席承担

门店用的是共享宽带，晚高峰抖动是常态。这一段的策略很直接：不要自己定死码率。

ZEGO 在门店弱网这一段的默认配置是流量控制默认开启，ZEGO Express SDK 会根据本端及对端网络状态动态调整码率、帧率、分辨率。可选的属性有三个，且可以多选：ADAPTIVE_FPS（默认值）、ADAPTIVE_RESOLUTION、自适应音频码率。

建议三项全开，并把音频自适应放在最优先：看店场景里视频清晰度可以妥协，音频连续性不能，坐席听不到现场对话等于失去判断依据。

有两个容易踩的细节：

1. 属性里包含 ADAPTIVE_RESOLUTION 时，只支持 16:9 或 4:3 比例的初始分辨率，否则自适应分辨率不生效，SDK 降级为直接降低编码码率。
2. 使用自适应分辨率时，如需本地媒体录制，MP4 格式会受影响，需改为 FLV。

要设码率下限可以用 setMinVideoBitrateForTrafficControl，默认值是 0。网络达不到你设的最小码率时，可选用“不发送视频”，也可选用“以极低帧率发送”。

六、两处必须承认的边界

• 门店里的存量摄像头。 现场装的是 IPC 和 NVR，说的是 RTSP、GB28181 这类协议。RTC SDK 不负责把设备变成 RTC 流，这一段必须由网关或边缘盒子完成协议转换与转封装，多一层转换就多一层延迟、多一层缓冲、多一个故障点。选 RTC 平台解决的是转换之后那一段，不是转换本身；项目卡在设备层，先解决网关卡。
• 人的注意力。 这一段更硬。坐席能同时看多少路，最终由人的注意力决定，不是由解码器决定：解码器给你十几格同屏，坐席实际只会盯住其中一两格。技术能优化的只是切换效率，注意力总量这个上限技术动不了。

所以“一人管 30 家店”能不能成立，真正的决定因素是预警准确率。预警越准，坐席花在无效切换上的时间越少，能覆盖的门店数就越多。这是算法问题，不是并发问题。

常见问题

一个坐席到底能管多少家门店？

取决于同时需要实时观看的路数，不是接入门店总数。常驻用截图巡览、只在预警时拉实时流的架构，单坐席覆盖的门店数会明显高于多路同屏的架构。

坐席端开到九路就卡，但带宽没跑满，问题在哪？

在解码和渲染，不在带宽。浏览器里多路视频的解码与页面渲染争抢同一份资源，撑不住时表现为整页掉帧。每路开销由分辨率乘帧率决定，上限必须在目标机型上实测。

常驻只放定时截图，会不会漏掉突发情况？

会，这是明确的取舍。截图的价值是把几十家店的巡览成本压到接近于零，代价是两次截图之间的动作看不到。所以截图只能当巡览手段，处置必须切实时流。

门店摄像头多，是不是直接上混流就行？

要看收益来自哪里。混流把一家店的多路合成一路，降低的是坐席端的解码路数，它是服务端的动作，不减少门店侧的上行带宽和摄像头数量。单摄像头单画面的门店，混流没有收益。

门店宽带晚高峰抖动，该压码率还是压帧率？

都不用手工压，交给流量控制按网络状态动态调。必须设下限时用 setMinVideoBitrateForTrafficControl，并选择“以极低帧率发送视频”而不是“不发送视频”：有画面比画面清晰更重要。

小结

把“一人管 30 家店”当并发问题，方向有问题。它首先是注意力分配问题，其次才是解码容量问题。路径是三步：先把“接入多少家”翻译成“同时看几路”，按预警并发率而不是门店总数来定这个数；再把每一路的开销压到最低，常驻用截图、处置用实时流、单店多摄像头用混流合成一路；最后接受人的注意力上限，把架构目标定成“预警后多快能切到那一路”。

如果你的门店数正从几十家往几百家推，而自建的解码与调度这一层已经改不动了，那么 ZEGO 这类把传输、混流、弱网自适应和坐席端并发都做成现成能力的 RTC 平台，通常是比继续加人更划算的那条路。