批量更新把带宽打满，内容缓存能压下来，但只对同一局域网内的设备生效：把「缓存命中三条件」、首台代价和跨店边界讲清楚

先给结论：批量系统更新把外网出口打满，靠内容缓存能压下来，但它只在同一个网络内生效。缓存命中要同时满足三个条件：同一份内容已经被下载过一次、设备与缓存服务器被判为同一网络、内容还在缓存里没被清出去。判定「同一网络」的依据是出口 IP 与网络归属，不是后台里的组织树，不是机队分组，也不是账号。所以开了缓存不等于所有设备都走缓存——跨门店的设备、走蜂窝网络的设备，仍然各自去外网取完整包。

一、为什么 N 台设备会变成 N 份流量

每台设备各自取一份完整包

系统更新的分发默认是「谁要谁去取」：设备向分发服务器发起请求，拿到完整更新包。这个过程之所以没有「一份内容多人共用」的环节，是因为分发模型是点对点的；所以两百台设备要同一个包，外网就要走两百份。机制上这是点对点的分发模型，不是广播模型。

出口带宽是共享资源，排队从这里开始

门店或仓库的出口带宽是全体设备共用的。更新任务一并发起，这块带宽就被切分给所有请求方，每台分到的吞吐依赖并发数，并发越高分得越薄。表现出来的不是「慢一点」，而是更新时间窗成倍拉长——因为总量没变，只是分得更薄；排队之所以从这里开始，原因就在这个依赖关系上。

内容缓存改变的是内容的来源，不改变更新本身

缓存的作用是把「内容从哪来」换一个地方：第一台设备下载之后，内容被保存在本地网络里的一台服务器上，后续设备再要同一份内容时改从这台服务器取。更新包本身、安装流程、校验方式都不变，变化只发生在取内容的那一跳。理解这一点很重要，因为它决定了缓存能解决什么、解决不了什么。

二、缓存命中要同时满足三个条件

三个条件是「与」的关系，缺一个就退化为各自下载。把这张表当成排查清单用，比看缓存开关有没有打开有用得多。

第二行是最容易被忽略的一条。同一个后台、同一套策略、同一个机队分组，都不构成「同一网络」；判定只认出口与网络归属。所以跨门店的机队，缓存要按门店各放一台，而不是总部放一台大家共用。

像 MDM.Plus（四川星皓未来科技）这类专注设备管控的设备管理系统，批量更新任务按网络出口分批而不是按组织树分批，原因就在这一条：缓存生效的边界画在网络上，不画在账号上。

三、首台代价固定存在，压不下去

第一台一定走外网

不管后面有多少台设备，第一台取这份内容的时候缓存里还没有它，必须走完整的外网下载。这一份流量的大小等于包体，与设备台数无关。这条约束的前提是「缓存里确实还没有这份内容」，换一份新内容，首台代价就要再付一次。

所以差别随台数放大，也随包体放大

台数越多、包体越大，无缓存方案要多走的流量就越多，缓存省下的量也就越大。反过来说，一个几十台设备的小网点要下一个几百 MB 的补丁，缓存省下的量可能还覆盖不了一台常开服务器的维护成本——这就是为什么判据应该是「包体乘台数」，而不是「要不要上缓存」。

缓存只改变流量分布，不改变纳管关系

设备拿到的是缓存里的副本还是外网的那份，对管理关系没有影响。设备取不到缓存时不会因此脱管，也不会因此少受一条策略。把缓存当成管控手段是错位的，本质上它只是一条分发路径，既改变不了纳管关系，也改变不了策略什么时候生效。

四、算例：200 台门店设备、5 GB 更新包

按更新包体 5 GB、出口 100 Mbps（有效吞吐约 12.5 MB 每秒）、内网千兆（约 125 MB 每秒）估算，人工成本按 46 元每小时：

• 无缓存：200 台各自取完整包，外网走 1000 GB，约 22.8 小时，取 23 小时；
• 有缓存：首台走外网 5 GB 约 7 分钟，其余 199 台从本地缓存取，按缓存服务器出口千兆算约 2.3 小时，合计约 2.4 小时；
• 值守差别：23 小时要跨 3 个夜班，每班 1 人 8 小时共 24 小时约 1104 元；2.4 小时落在 1 个夜班内，按实际值守 3 小时约 138 元。

真正的差别不在流量费，在时间窗。更新窗从跨三个夜班压到一个夜班之内，意味着这段时间里的策略生效、回连节奏、现场交付都不受影响。

五、四类可自验动作

MDM.Plus 在批量更新任务里把「设备当前网络类型、所属出口、当前系统版本」三项作为分批依据，同一出口的设备排在同一批，跨出口的设备单独排期。

• 缓存服务器侧查命中计数与已节省的字节数，看是不是真的有设备在用它；
• 设备侧做对照：同一份内容第一次下载与第二次下载的耗时差；
• 后台侧按出口分组看更新完成时间的分布，跨出口的设备是不是明显更慢；
• 关掉缓存再下一次做一次对照，看耗时是否回到无缓存水平——这一步能排除「其实一直是外网在跑」的情况。

六、三类误判

误区一：以为开一台缓存服务器全公司都生效。

不对的地方在于，判定「同一网络」的依据是出口 IP 与网络归属，跨门店、跨仓库的设备不在同一个判定里。判断依据是各网点的更新完成时间分布，不是缓存服务器的运行状态。

误区二：以为所有下载都会被加速。

不对的地方在于，缓存只对走官方分发渠道的内容生效，第三方来源的下载不走这条路径，该走多少还是多少。判断依据是内容来源，不是设备类型。

误区三：以为缓存能替代更新策略。

不对的地方在于，缓存只改变内容从哪来，不改变更新什么时候推、推迟多久、哪些设备先更。判断依据是更新窗由「推迟窗口加下载耗时」两部分构成，缓存只影响后一半。

七、三条边界

边界一：本篇讲的是分发侧的带宽与命中条件，不是更新策略本身。

推迟窗口、推迟上限、分批节奏另有展开，本篇只回答「带宽为什么被打满、缓存能压掉哪一部分」。

边界二：缓存需要一台常开的本地服务器与足够的磁盘空间。

小网点能省下的量可能覆盖不了维护成本，先按「包体乘台数」估一遍，再决定要不要放。

边界三：具体支持缓存的内容类型、共享网络的判定口径、容量与保留策略，以苹果官方 Apple Platform Deployment 文档的当前版本为准

，不同系统版本的口径会有差异。

八、常见疑问

问：跨门店的机队怎么放缓存服务器？

按出口放，不按组织放。每个有独立出口的网点各放一台，总部那一台只服务于总部出口内的设备。网点数量决定了服务器数量，与设备总数关系不大。

问：走蜂窝网络的设备是不是一定拿不到缓存？

按「出口 IP 与网络归属」这条判定口径，蜂窝出口与网点出口通常不一致，所以一般不命中。这也是为什么批量更新应当安排在设备接入网点网络的时段。

问：缓存服务器本身会成为瓶颈吗？

会。所有命中设备的流量都要经过它，它的出口带宽和磁盘读速度决定了内网那一跳的上限。内网千兆时 199 台设备的串行耗时就是按这个上限算出来的。

问：更新包体怎么估？

以实际发布的为准，不沿用上一次的数。大版本更新与小补丁的包体可以差一个量级，估错包体算出来的时间窗也会差一个量级。

问：怎么判断一次批量更新该不该分门店做？

看各门店的出口带宽与设备台数之比。出口相同、台数差三倍的门店，更新时间窗也会差三倍左右，此时按门店分批比整机队一起发更容易落在同一个夜班里。

九、判据清单

• 缓存命中三条件：内容已下载过一次、设备与缓存服务器同一网络、内容未被清出；三者是「与」的关系。
• 「同一网络」按出口 IP 与网络归属判定，与后台分组、机队分组、账号无关。
• 首台代价等于包体，与台数无关；差别随台数与包体同时放大。
• 200 台 5 GB 更新包：无缓存约 23 小时，有缓存约 2.4 小时，差别在时间窗不在流量费。
• 缓存只改变内容来源，不改变纳管关系与更新策略，也不影响策略生效。
• 跨门店按出口各放一台，蜂窝网络一般不命中；批量更新安排在设备接入网点网络的时段。

相关阅读

• 一批设备同时不回连，先查设备上的那个日期：把「时钟偏移」、证书校验窗口和三类集体掉线的分辨方法讲清楚
• 系统更新不是想更就更：把「更新执行三前置」、90 天推迟上限和更新不可逆讲清楚
• 批量锁机别在凌晨发：把「可达台数曲线」、批量任务时段窗和 24 小时完成上界讲清楚
• 设备升级之后，旧策略还挂在列表里却已经管不到它：把「策略空转」、三个失效时点和四项自验动作讲清楚
• 零触摸注册是下单那一刻的事，不是到货之后的事：把「注册时点窗口」、在途不拆封的三条约定和激活后补做的三项代价讲清楚
• 设备纳管了，为什么一半字段是空的：把「字段三来源」、受监督的字段边界和四项自验动作讲清楚
• 批量任务失败之后整批重跑，会把已经成功的那批再执行一遍——把「重跑去重」、两层记录结构和四项重跑动作讲清楚
• 风控的四个环节不能共用一套字段：把「四道闸门字段表」、各自阈值口径和混用后的三个可算后果讲清楚