CDN工作原理及其在淘宝图片业务中的应用，字节跳动桌面运维面试题

最新推荐文章于 2024-05-19 17:21:24 发布

2401_84024576

最新推荐文章于 2024-05-19 17:21:24 发布

阅读量473

点赞数 3

分类专栏： 2024年程序员学习文章标签：运维 java spring

本文链接：https://blog.csdn.net/2401_84024576/article/details/137540764

版权

2024年程序员学习专栏收录该内容

235 篇文章 0 订阅

订阅专栏

源站img-picasso处理图片，以及查询商品DB，都是非常消耗资源的。CDN及商品的缓存命中率降低后，对源站img-picsasso以及db会产生巨大的压力。

拿CDN缓存为例，简单计算一下，CDN平时的命中率是98%，假设命中率降低1个点，对源站的压力就会增加1/3（原本承担2%的流量，现在需要承担3%的流量），意味着img-picasso需要扩容1/3。如果全网一半的图片都同时变化，cdn的命中率降到50%，对img-picasso的访问量就会增加25倍，这个扩容成本肯定没法接受。

解决这2个问题，对应的有2个办法：

改图保持图片URL不变，可以避免商品链路的缓存失效。
在访问高峰到来之前，提前预热图片到CDN，可以避免CDN缓存失效对源站的压力。

下面，介绍下我们具体是怎么做到这2点的。

===

频繁换图的应对方案

=============

▐ 改图保持图片URL不变

图片内容发生变化时，执行下面2个操作：

更新OSS内容：使用新的图片内容替换OSS中老的图片内容
刷新CDN缓存：清除CDN之前缓存的图片内容

这样，用户再次访问图片时，发现CDN没有缓存，就会回源到img-picasso，从OSS拉取新的图片内容。

由于图片URL没有变化，就不必去更新商品中心的图片链接，这样商品链路的缓存可以保持不变。

在真正实施这个方案的过程中，遇到了几个问题，简单跟大家分享下：

OSS三地同步

淘宝的图片空间，承载了淘系所有图片的上下行稳定性保障，为了保障高可用，一份资源会存储到三地OSS。图片上传时，默认只上传一地，利用OSS的能力，自动同步到另外两地。

但是使用URL不变方案，CDN缓存已经清除完成后，如果另外2地的OSS还未同步完成，用户访问后，就会回源到旧的图片内容，发现图片内容没有变化。

针对该问题，我们将异步同步OSS软链的模式，改成三地同步建软链，三地都返回成功后，再去清除CDN缓存，这就保证了用户访问的图片一定是最新的内容。

图片尺寸收敛

同一张商品图片会用于不同的场景坑位展现，不同的坑位对图片的尺寸有不同的要求。为此，图片空间提供了一项功能，可以方便的生成不同尺寸的缩率图。只需要访问图片时，给图片增加不同的后缀，img-picasso源站就可以按要求进行图片进行缩放。

由于历史原因，之前对缩放的尺寸种类没有限制，导致CDN上的图片后缀格式多达2400种+，TOP6格式覆盖率46%，TOP15格式覆盖率64%。这意味着，一张图片，在cdn上最多可能有2400+个不同的url，当图片内容变化后，要把这些缓存全部清掉，才能保证所有用户看到的图片都是新内容。

为了解决这个问题，我们对域名格式进行了收敛。

图片空间对于图片质量压缩参数的规则如下：

图片质量参数常见有一下8种形式：Q90、Q75、Q50、Q30、q90、q75、q50、q30
图片锐化参数常见有一下3种形式：s100，s150，s200

我们重新将图片质量定义为高质量图片和低质量图片，收敛格式为 q90 和 p50s150

这样，就可以把2000多种格式收敛到6种主要格式，CDN清除缓存才变得可行。

多副本清除CDN缓存

通过图片尺寸收敛，每张图片只需要清除6个不同的url就可以了，那能不能进一步提升刷新效率呢？

为此，阿里云CDN为我们提供了多副本刷新的解决方案：每种不同后缀的图片，作为图片的一个副本，在CDN的swift层增加一层KV结构，存储url和不同副本的映射关系，清除缓存时，可以通过该结构找到所有副本，实现快速清除所有副本。这样，每张图片，我们只需要调用一次CDN清除缓存接口就可以了，极大提升了CDN缓存刷新效率。

图片域名收敛

淘系的图片域名有300多种，主要有下面2个原因：

图片完整的链接太长，所以存储时经常只存最后一段，业务自己来拼域名，很多业务就自己申请了一个图片域名来拼。
PC时代，浏览器对同一域名下的并发请求数是有限制的，不同浏览器不一样，一般6个左右。为了突破该限制，一些业务就会申请多个域名，随机的拼不同的域名。

前面我们讲过，CDN的缓存是跟域名绑定的，不管是缓存命中还是缓存清除，都只能针对一个域名。

我们显然不可能改一张图，就去对300个域名调用CDN刷新。于是我们考虑对图片域名进行收敛，使得用户对图片的访问都路由到同一个域名，我们希望将所有的图片访问统一收敛到picasso.alicdn.com，具体实现方式如下：

对于手淘和猫客客户端，图片访问都收口在图片库，我们推进图片库进行改造，符合一定规则的url，统一收敛到picasso.alicdn.com，实现了域名的一刀切。
对于PC浏览器端，就比较麻烦了，没有统一收口的地方。我们只能退而求其次，针对访问最多的6大域名，在cdn上配置域名转发规则，重定向到picasso域名。

通过这种方式，我们实现了全网99%以上的图片访问流量都路由到picasso域名，图片内容发生变化时，通过清除picasso域名的cdn缓存，就能保证基本所有的场景都能看到新的图片内容。

客户端及浏览器缓存

通过多副本和图片域名收敛，cdn的缓存问题得到了解决。但在cdn之上，用户图片访问首先是来自客户端或者浏览器，这里也会有一层缓存。

大家知道，浏览器的缓存都遵循标准的http max-age协议，指定该header后，到了时间图片就会失效，访问到新的图片。所以我们可以在源站img-picasso回源给cdn时，添加max-age协议头，值为1分钟，cdn会原封不动的透给浏览器，这样浏览器就可以实现1分钟内图片缓存失效，重新到cdn拉新的图片资源。

对于手机淘宝客户端，我们在原有的LRU缓存机制之上，另外支持标准的http协议。这样，手机淘宝也实现了1分钟内图片缓存失效。

▐ 提前预热CDN图片

通过改图保持图片URL不变，我们解决了改图对商品链路缓存的影响。但是，图片变化时，虽然URL没有变，但我们清除了CDN缓存，导致用户访问时还是会回源到img-picasso源站，所以对图片源站的压力依然存在。

我们发现，商品的价格变化大部分发生在大促节奏变化的时刻，基于这个特点，我们通过提前合成图片，提前预热到CDN，可以实现图片切换瞬间生效，同时对源站没有压力。具体方案如下：

**提前合成多波段图片：**我们知道大促期间商家集中换图的时间点后，按这些时间点把图片的展示分成多个波段，每个波段图片提前合成，并提前将图片URL写入到商品中心扩展结构中。
**图片访问路由：**营销系统根据配置的大促氛围切换计划，告诉鹿班图片二方包，当前是哪个波段，鹿班根据当前波段及场景，返回正确的图片URL给各个场景。
**图片渲染：**各个场景拿到图片URL后，结合自身的业务逻辑，决定是否要展现该图片。
**CDN图片预热：**为了避免图片集中切换时，把源站击垮，我们会在集中切换前把这些冷图片内容预热到CDN。
**波段内图片变化：**提前合成各个波段图片后，商家可能会临时发券/改价，导致商品价格再次变化，对于这类换图需求，为了避免更新商品中心的图片URL，我们通过本文上一章节刷CDN缓存的方式实现。

===

总结和展望

=========

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。