Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

基于 CDN 的「推送式」缓存

  早期的应用都是将配置以常量的形式定义到代码中,打包到应用里,每次修改时改代码再重新发布应用。后来,配置被以文件的形式单独存储,修改配置只需要修改配置文件即可,但依然要发布应用。再后来,应用被专门的服务管理,应用会在打开时向服务器发请求来同步配置。
  对于 Web 应用,「同步配置」这个操作是非常频繁的。因为配置会在任何时候被修改,为了让客户端可以及时生效,这些配置是不能缓存的。如果配置以服务的形式提供,客户端每次都有请求同步,那对服务器而言将是一笔巨大的开销。虽然配置只是一些静态文件,甚至完全是内存中读取的。但对于请求量等于 PV 的海量请求,服务器的压力依然是很大的。
  除了服务器压力外,还有节点单一的问题。假如我们的服务器在上海,那么只有上海附近的用户可以快速同步到配置,更远的用户可能碍于物理上的限制,需要更长时间才能同步到。
  我的想法是,让 CDN 来做这件事也许会更好。CDN 不仅解决了节点单一的问题,还解决了自己的服务器海量请求的问题。(其实更重要的是 CDN 的流量比服务器流量便宜)
  具体怎么操作呢?首先,将自己的服务器作为 CDN 的源站。这样用户访问 CDN 节点后,CDN 便会到我们自己的服务器上取资源。但如果只是这样,会导致所有请求都回源,不仅没啥帮助,反而多了一层代理,让请求变得更慢。所以一定要让 CDN 这一层做缓存,这样才可以减少回源率,加快客户端响应。但又不能让终端用户缓存,要不然会导致客户根本不发请求,无法更新配置。也就是说,我们在设 max-age=0 之外,还需要设置 s-maxage=31536000。
  我们需要的是所有的客户端本地不缓存配置文件(在 http 这一层上不缓存,程序级的缓存还是可以有的),总是都到 CDN 上取资源,而 CDN 回源由我们自己的服务器来控制(几乎所有的 CDN 提供商都支持刷新缓存的 API)。每当服务器的配置更新时,我们主动调用 CDN 的缓存刷新。然后 CDN 就会疯狂地回源,直到所有 CDN 节点都更新资源。
  虽然自己的服务器对更新资源这件事还是被动的,但这样部署之后调用 CDN 刷新缓存 API 这个动作就会变成一种类似「向所有 CDN 节点推送资源」一样的主动操作。
  另外,用这种方式来更新「应用的配置」只是一个例子,这种方式还可以用来操作其它具有类似需求资源的场景。
网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^