无人零售云值守：一个坐席管 30 家店，切流与并发怎么设计
内容提要
无人零售云值守中，“一人管30家店”的瓶颈在于预警后切流速度与坐席注意力，而非延迟。容量应按同时观看路数规划：常驻用定时截图巡览，预警时拉实时流；单店多摄像头可用服务端混流合成一路，降低坐席端解码；门店弱网由流量控制动态调码率帧率，音频优先。最终上限由预警准确率和人的注意力决定。
延伸解读
容量规划：从门店总数转向同时观看路数
文章指出，云值守容量不应按接入门店总数计算，而应按同时观看路数规划。因为门店大部分时间正常，异常稀疏，坐席无需同时盯住所有门店。常驻用定时截图巡览，预警时再拉实时流，可大幅降低解码资源占用。这种按需拉流的方式，让单坐席覆盖门店数显著提升，但代价是截图间隔内的动作可能遗漏。
混流的价值与边界：降低坐席端解码，不减少门店上行
对于单店多摄像头场景，服务端混流可将多路视频合成一路，使坐席端解码路数从4降到1，缓解浏览器解码压力。但混流不减少门店侧摄像头数量和上行带宽，四路仍需各自上行。混流需单独开通，有任务限制和计费影响。因此，混流适用于多摄像头门店，单摄像头门店并无收益。
弱网策略：动态自适应优先，音频连续性最关键
门店共享宽带波动时，应开启流量控制，让SDK根据网络动态调整码率、帧率和分辨率。建议三项自适应全开，并优先保证音频自适应，因为坐席听不到现场对话会失去判断依据。需注意自适应分辨率对初始比例有要求，且可能影响本地录制格式。设置码率下限时，应选择极低帧率发送而非不发送视频，确保画面不中断。
最终上限：预警准确率与人的注意力
技术优化可提升切流效率，但坐席能同时处理的门店数最终受限于人的注意力。解码器可提供多路同屏，但坐席实际只能关注一两路。因此，一人管30家店能否成立，关键在预警准确率：预警越准，无效切换越少，覆盖门店数越多。这是算法问题，而非并发问题。架构目标应定为预警后多快能切到那一路。
Q&A
无人零售云值守中，一个坐席能管多少家门店？
取决于同时需要实时观看的路数，而不是接入门店总数。采用常驻截图巡览、只在预警时拉实时流的架构，单坐席覆盖的门店数会明显高于多路同屏的架构。
为什么降低延迟不能解决坐席看不过来的问题？
因为决定坐席效率的不是延迟，而是预警后切到目标画面的速度。主流RTC延迟已在200毫秒量级，看画面容忍度宽，500毫秒到1秒都不影响。真正稀缺的是坐席注意力，减少切换次数才是关键。
云值守架构中，常驻巡览为什么用定时截图而不是实时视频？
因为证明门店正常不需要实时流。云端截图默认每10秒截一次，输出JPG，几乎不占解码资源，坐席扫一眼就能发现异常。代价是两次截图之间的动作看不到，所以截图只用于巡览，处置必须切实时流。
单店多摄像头时，如何降低坐席端的解码压力？
使用服务端混流，将一家店的多个摄像头画面合成一路，坐席端解码路数从多路降为1路。混流需要单独开通，一个任务最多输出4路不同分辨率，仅支持服务端混流，且不减少门店侧上行带宽和摄像头数量。
门店宽带波动时，应该手动调整码率还是帧率？
都不用手动，应交给流量控制动态调整。建议开启自适应帧率、自适应分辨率和自适应音频码率，并优先保证音频。如需设下限，用setMinVideoBitrateForTrafficControl，并选择“以极低帧率发送视频”而不是“不发送视频”。
无人零售云值守中，哪些边界是技术无法突破的？
两个边界：一是存量摄像头协议转换，RTC SDK不负责将RTSP/GB28181转为RTC流，需网关或边缘盒子完成，会引入延迟和故障点；二是人的注意力上限，坐席能同时看多少路最终由注意力决定，技术只能优化切换效率。
