CloudFront预热工具介绍

1.  背景

《流浪城堡》项目组侧根据用户到服务器端延迟打点数据推断以及客服反馈用户下载客户端热更新可能存在卡顿、慢的情况存在，运维侧能否提思路或技术优化方案

  游戏侧已在V3.5加上客户端热更新下载耗时打点数据，下周可提供一份玩家真实下载耗时相关数据

2. CDN预热介绍

概念

终端CDN节点上先于外部真实用户获取源站侧的文件，将资源缓存到CDN节点，CDN节点对应首批真实外部用户请求资源时，即可直接从CDN节点获取到最新的资源，无需再回源站获取。预热功能会提高缓存命中率，尤其是在传递⼤⽂件时⾮常有⽤，有效降低时间段内源站的负载。

场景

• 运营活动

运营一个大型活动时，提前将活动页涉及到的静态资源预热至CDN节点，活动开始后用户访问的所有静态资源均已缓存至CDN加速节点，由加速节点直接响应。

• 安装包发布

新版本安装包或升级包发布前，提前将资源预热至CDN加速节点，产品正式上线后，海量用户的下载请求将直接由CDN加速节点响应，提升下载速度，大幅度降低源站压力，提升用户体验。

CDN访问示意图

 

3.  预热工具设计

思路

模拟用户下载更新行为，通过遍历预热资源url列表和PoP节点，将资源都完整下载一遍。

下载方式

• 单地域服务器(分布式)下载所有任务，地域&网络有明显匹配问题
  • 多地域服务器分布式下载任务，多地部署服务器&维护、费用高
  • 多地域Lambda函数服务分布式下载任务，按使用的计算时间付费，代码未运行时不产生费用

工具示意图

 

前端展示

 

后端Lambda函数代码片段

 

4.  其他问题

1. 预热是否需要对HTTP和HTTPS分别预热？

不需要，只需预热HTTP或HTTPS其中一种即可。

2. 为什么阿里云控制台不提供L1节点预热功能？

L1节点过多，而且不能保证覆盖，例如预热全部cdn的L1节点，那其实就是L1和L2都要有缓存，这样会导致频繁回源，虽然回源次数和L2预热是一样的，但是内部就会有问题，假设一个L2节点服务10个L1节点，那对着十个节点提交预热任务，这十个节点要同时访问L2拉取文件，那就会有问题，源文件如果几十个G，此时预热逻辑应该是怎么样的，是优先保证第一个L1发起任务的预热完成吗？那其他九个要怎么办，毕竟一条链路只能处理一个文件，不可能L2一个节点同一时间和源站建联10次拉取同一个文件，这个就会出现大量预热失败的情况，并不是节点有问题，也不是源站有问题，而是预热逻辑没法写，还有一种情况，为减少预热节点，您这边按目前的覆盖去预热，这样按理说没问题，可覆盖是会变更的，比如您凌晨预热好了节点，需要应对晚高峰期间的业务突发，但是实际晚高峰的时候，对应服务您域名的节点又会变化，因为量级上去了，需要多个节点服务，那预热节点也会不够用，预热效果也不好。综上L2回源预热是目前最好的预热方案，是可以兼容回源并发和CDN内部耗时的预热方式。

3. 阿里云控制台上预热状态完成，是真正完成了预热了吗？

阿里云控制台上显示的预热状态完成，进度100%，仅代表预热任务下发L2完成，并不代表预热成功，不能说明资源缓存在了边缘节点上。资源能否成功缓存在边缘节点上，受多种因素的影响（链路质量，源站带宽），尤其当源站在海外时，预热效果更差，很可能超过半数以上的 L2 边缘节点都没有成功缓存（但在控制台上看不出来）。

说明：预热任务状态为成功，表示预热任务提交成功，并不能代表文件已经预热结束

4. 阿里云的预热方式是拉取还是推送？

阿里云CDN预热是下发任务去源站拉取文件，CDN预热仅支持拉取式任务，因此不管是控制台自助执行预热，还是要阿里云技术后台预热，都是下发任务到L2/L1，控制台自助只支持L2，阿里云技术操作可以到L1。

5. 如何查看预热结果？

阿里云

CloudFront

 

补充：

获取aws cloudfront pop节点的网站

https://www.feitsui.com/zh-hans/article/3

示例：

 

假如我现在的cloudfront域名是d2ohst799nr3ov.cloudfront.net

以BNE50-P2节点为例，那当地的pop点的域名就是d2ohst799nr3ov.bne50-p2.cloudfront.net

那d2ohst799nr3ov.bne50-p2.cloudfront.net这个域名对应的几个pop点的ip为:

dig  d2ohst799nr3ov.bne50-p2.cloudfront.net

 无论在哪里执行dig这个命令，返回的结果都是一样的。