1.CDN缓存
2.解决方案
1.CDN缓存
CDN并不会主动把旧包和新包放在一起, 所谓的"新旧包混杂", 本质是相同文件名的前提下, CDN不同边缘节点的缓存状态不
一致 —— 有的节点存着旧包, 有的节点拉取了新包, 用户访问不同节点就拿到不同版本, 从用户视角看就像是"混在一起了"
1).前提: 只针对"同名文件", 比如都是hotupdate.zip
如果热更包文件名不同(v1.0.0和v1.0.1), CDN会把它们当成完全不同的两个文件, 各节点会独立缓存, 根本不存在混杂,这
也是为什么改文件名能从根源解决问题
混包只发生在"文件名不变, 只替换源站文件"的场景下, 核心原因: 3个CDN特性导致节点缓存状态不一致
a.每个CDN节点是"独立的小仓库", 互相不通气
全国的CDN边缘节点彼此之间没有数据同步, 北京节点存了什么版本、缓存有没有过期, 上海节点完全不知道, 每个节点只管
自己的库存和计时
源站把hotupdate.zip从v1换成v2后, 不会主动通知所有节点"赶紧换包", 节点们只能靠自己的缓存过期规则判断是否需要
更新
b.缓存过期时间"节点各自计时", 起点完全不同
节点的缓存有效期, 比如7天, 是从"这个节点第一次拉取文件的时刻开始算的, 不是源站发布文件的时刻"
比如:
- 北京节点1月1日9点被用户触发, 拉取了v1包, 有效期到1月8日9点
- 上海节点1月2日14点被触发, 拉取v1包, 有效期到1月9日14点
- 源站1月7日把文件换成v2后, 北京、上海节点的缓存都没到期, 会继续存着v1包
c.节点只会"被动更新", 不会主动检查源站
缓存没过期的节点, 会默认自己的库存是"最新的", 用户请求时直接返回本地旧包, 不会去源站确认"文件是不是换了"
只有两种情况节点会去源站拉取新文件
- 节点的缓存过期了, 用户请求时会先去源站校验, 发现文件更新就拉取v2
- 节点从来没缓存过这个文件(新节点/无用户访问过), 用户请求时直接去源站拉取最新的v2
最终混杂的结果: "不同节点返回不同版本", 源站替换同名文件后, CDN的节点会分成三类
- ✅ 缓存未过期的节点: 继续返回旧包v1, 比如北京
- ❌ 缓存已过期的节点: 去源站拉取新包v2, 返回v2
- ❌ 无缓存的节点: 直接去源站拉取新包v2, 返回v2
用户访问CDN时, 会被自动分配到就近的节点:
- 被分配到北京节点的用户 -> 拿v1旧包
- 被分配到上海新节点的用户 -> 拿v2新包
从用户视角看, 就是"同一个下载地址, 有的人拿到旧包, 有的人拿到新包", 也就是"新旧包混在一起了"
CDN的"混包"不是CDN主动将新旧包共存, 而是同名文件下, 各边缘节点的缓存过期时间不同、缓存状态不一致, 导致不同节
点返回不同版本的文件, 最终体现在用户侧的版本混乱; 只要给热更包加唯一标识(版本号/哈希), 让新旧包文件名不同,CDN
会将它们视为独立资源, 各节点的缓存互不影响, 就彻底不会有混杂问题了
2.解决方案
解决"用户识别最新包"的关键是: 在CDN上放一个固定文件名的版本清单文件(比如version.json), 这个文件是"导航页", 它
本身文件名不变(但设置短缓存), 里面记录着最新热更包的"唯一标识文件名", "版本号", "CDN地址"等信息; Unity客户端
启动时, 先下载这个清单文件, 对比本地版本, 就能知道有没有新包、新包的CDN地址是什么, 然后下载对应的包
a.先确定CDN上的文件结构, 这是避免缓存问题的基础
b.版本清单文件(version.json)内容示例
这个文件是核心, 内容要包含足够的信息让客户端判断是否更新, 示例如下
- 发布新包时, 只需要修改这个version.json里的内容, 比如把latestVersion改成1.0.1, packageName改成新包名, 然后
重新上传到CDN即可
- 给这个文件设置CDN缓存策略: Cache-Control: max-age = 60(缓存60秒), 确保客户端每次都能拿到最新的清单
c.热更包的命名与缓存
- 热更包(Unity的AssetBundle包)命名必须带唯一标识(版本号/哈希值)
比如: hotupdate_v1.0.0.unity3d、hotupdate_v1.0.1.unity3d
- 给热更包设置CDN长缓存: Cache-Control: max-age=31536000(缓存1年), 因为文件名唯一, 不会和旧包混杂, 缓存越久
越省CDN资源
转载自CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/xxxxxxxx___/article/details/157726157
