如果缓存过期了 , 就真的无计可施了吗?
当然不是!
云防护 CDN 系统早已考虑到了这种情况 , 并有至少三种解决对策:
(1)通过建立缓存父层将回源流量进行收敛 。
我们把 CDN 缓存节点向 Web Server 发起的请求称为回源请求 , 将 Web Server 称为源站 。当静态文件过期时 , 缓存节点不直接回源 , 而是先请求上一级的缓存节点 , 由上一级的缓存节点回源 。这是一个树型结构 , 父层节点在顶层 。大量缓存节点在叶子处 , 它们访问父层 , 再由少量的父层节点回源 。通过这样的层级收敛 , 将大量的缓存节点请求 , 转化成少量的父节点回源请求 , 从而大大减小源站的压力 。
(2)缓存节点至父层合并回源 。
大量的缓存节点向父层(或源站)发起请求时 , 也势必会给父层节点造成很大的压力 。针对这种情况 , 云防护有自研的解决方案 , 可将同一个文件的大量并发请求 , 合并成一个或者少量请求返回给父层 , 从而使父层的请求数大大减少 , 缓解父层压力 。而这种技术 , 父缓存节点是无感知的 。我们将这个技术称之为“合并回源” 。目前 Squid/Apache Traffic Server 等开源软件 , 都采用了这种技术 。
(3)条件回源 。
当缓存节点发现文件过期时 , 常规做法是重新下载整个文件 , 覆盖旧文件 。在文件体积比较小的情况下 , 这种方式问题不大;可一旦文件体积过大 , 大量的文件更新 , 对服务器也是一种考验 。此时 , 我们会启用条件回源:当缓存节点认为缓存文件过期时 , 源站文件可能并未真正更新 , 只是到了例行的过期检查时间点而已 。此时 , 我们会在 HTTP 头部携带特定的信息 , 来询问源站是否真的更新了文件 。事实经验告诉我们 , 在大部分情况下 , 源站文件并没有真正更新 。通过这种方法我们可以避免粗暴无用的重复下载整个文件 。
这样看来 , 在大部分情况下你都无需担心了 。但还有这样一种情况可能发生 , 那就是 Web Server 由于种种原因 , 无法提供正常服务了(比如由于自身原因 , 出现短暂宕机)!而此时静态文件又恰好过期 , 这样一来 , 缓存节点的流量会导向源站 , 源站又不能正常提供服务 , 在访客看来 , 网站就无法访问了 。
这可怎么办呢?!
不用怕!
云防护系统也同样考虑到了这种情况 , 并至少提供以下三种解决方案:
(1)使用旧缓存文件
当缓存节点回源时 , 源站有故障 , 会返回异常页面 , 如 502/504 , 或超时等 。此时 , 缓存节点直接使用旧文件响应访客 。在访客看来 , 能正常访问到内容 , 并不会感知到源站出现故障 。此外 , 我们还会对旧文件强制延长一个短的过期时间 , 防止短时间内出现频繁回源的情况 。
(2)永久在线
对于开启此功能的网站 , 云防护会通过自研的爬虫程序 , 定期抓取客户源站的内容 , 缓存到我们的数据服务器上 , 我们称之为“镜像” 。当源站出现问题时 , 缓存节点也可以将访问请求导向“镜像”文件 , 从而正常响应数据给访客 。
(3)重保只读
和永久在线原理类似 , 重保只读也是通过爬虫生成“镜像”文件 。只是 , 此时“镜像”可以充当源站使用(伪源站) , 源站在重保只读期间 , 可完全关闭 。所有的请求或攻击 , 都不会导向真正的源站 , 这样即可保证重要时期源站不会因攻击或访问量过大而出现问题 。
当然 , 以上策略都是可能有损的 。前面讲过 , 对动态文件的请求是非幂等的 , 即使强制缓存起来 , 也没有大太作用 。另外像 SNS 网站有较强的交互性 , 除了下载以外 , 还会上传文件(HTTP POST/PUT) 。这些数据 , 目前都没有办法用以上策略解决 。当 Web Server 出现问题时 , 还需要网站尽快针对自身问题从根源上进行修复 。
至此 , CDN 缓存系统和 Web Server 各司其职 , 相得益彰 。你不知道的是 , 云防护 CDN 缓存内部其实还有许多其他方面的优化:
推荐阅读
- UEFI+GPT和Legacy+MBR两种模式安装的系统有什么区别
- win10操作系统和CPU处理器分32位和64位两种,它们的区别是什么
- 真皮皮包脏了清理小窍门 皮包沾水有痕迹怎么办
- 日本核废水已排了吗 日本倒核废水了没有
- Spring Boot 入门学习指南
- 淘宝金牌卖家需要什么条件 淘宝金牌卖家在哪里开通
- php为什么没有多线程?
- 火烧云的形状像什么 什么是火烧云,火烧云是怎么形成的
- 梦见自己和前夫和好了又遇到丧事 梦见自己和前夫和好了还有个女儿
- 淘宝上面签的合同有效吗 淘宝合同协议怎么签
