淘寶的圖檔通路，有98%的流量都走了CDN緩存，隻有2%會回源到源站，節省了大量的伺服器資源。
但是，如果在使用者通路高峰期，圖檔内容大批量發生變化，大量使用者的通路就會穿透cdn，對源站造成巨大的壓力。
今年雙11，淘寶鹿班的主圖價格表達更新項目，就面臨了這種挑戰，讓我們看看是如何解決的吧。
CDN工作原理
内容分發網絡（Content Delivery Network，簡稱CDN）是建立并覆寫在承載網之上，由分布在不同區域的邊緣節點伺服器群組成的分布式網絡。
CDN應用廣泛，支援多種行業、多種場景内容加速，例如：圖檔小檔案、大檔案下載下傳、視音頻點播、直播流媒體、全站加速、安全加速。
借用阿裡雲官網的例子，來簡單介紹CDN的工作原理。
假設通過CDN加速的域名為www.a.com，接入CDN網絡，開始使用加速服務後，當終端使用者（北京）發起HTTP請求時，處理流程如下：
1、當終端使用者（北京）向www.a.com下的指定資源發起請求時，首先向LDNS（本地DNS）發起域名解析請求。
2、LDNS檢查緩存中是否有www.a.com的IP位址記錄。如果有，則直接傳回給終端使用者；如果沒有，則向授權DNS查詢。
3、當授權DNS解析www.a.com時，傳回域名CNAME www.a.tbcdn.com對應IP位址。
4、域名解析請求發送至阿裡雲DNS排程系統，并為請求配置設定最佳節點IP位址。
5、LDNS擷取DNS傳回的解析IP位址。
6、使用者擷取解析IP位址。
7、使用者向擷取的IP位址發起對該資源的通路請求。
- 如果該IP位址對應的節點已緩存該資源，則會将資料直接傳回給使用者，例如，圖中步驟7和8，請求結束。
- 如果該IP位址對應的節點未緩存該資源，則節點向源站發起對該資源的請求。擷取資源後，結合使用者自定義配置的緩存政策，将資源緩存至節點，例如，圖中的北京節點，并傳回給使用者，請求結束。
從這個例子可以了解到：
1、CDN的加速資源是跟域名綁定的。
2、通過域名通路資源，首先是通過DNS分查找離使用者最近的CDN節點（邊緣伺服器）的IP
3、通過IP通路實際資源時，如果CDN上并沒有緩存資源，則會到源站請求資源，并緩存到CDN節點上，這樣，使用者下一次通路時，該CDN節點就會有對應資源的緩存了。
淘寶鹿班圖檔業務背景
商品的主圖貫穿整個導購和交易鍊路，相比文字，圖檔更能吸引眼球，主圖對消費者的購物決策有很大的影響。主圖上表達的内容各式各樣，但其中一定少不了的一定是價格的表達。
長期以來，主圖上的價格表達都是商家自己維護，商品價格發生變化後，手動去換圖。這樣做，會帶來3個問題：
1、價格的準确性：商家手動填寫的圖檔價格，跟實際的購買價可能不一緻，造成不好的使用者體驗。
2、價格更新的及時性：有時候，由于優惠券/品類券的生效失效，會導緻商品的價格變化會很頻繁，商家根本來不及換圖。
3、商家的操作成本：手動修改圖檔的價格，成本還是很高的，需要通過ps等軟體修改圖檔，重新上傳，編輯商品。
今年雙11，淘系技術部-鹿班團隊，試圖通過技術手段來解決這些問題。當商品價格發生變化後，系統自動計算新的價格，自動合成圖檔，然後更新商品主圖。
我們知道，淘寶網有上億的商品，光大促商品就有幾千萬，是以，價格變化導緻的圖檔變化頻率非常高。最高的就是在雙11的0點，全部大促商品的價格都會由日常價格變成大促價格。
這就意味着，大促高峰期，有上千萬的圖檔剛生成就會被使用者通路。那這個情況會産生什麼問題呢，讓我們先了解下淘寶的圖檔空間和CDN的架構，就清楚了。
淘寶圖檔空間和CDN的架構
淘寶整個圖檔的通路鍊路有三級緩存（用戶端本地、CDN L1、CDN L2），所有圖檔都持久化的存儲到OSS中。真正處理圖檔的是img-picasso系統，它的功能比較複雜，包括從OSS讀取檔案，對圖檔尺寸進行縮放，編解碼，是以機器成本比較高。
CDN的緩存分成2級，合理的配置設定L1和L2的比例，一方面，可以通過一緻性hash的手段，在同等資源的情況下，緩存更多内容，提升整體緩存命中率；另一方面，可以平衡計算和IO，充分利用不同配置的機器的能力。
使用者通路圖檔的過程如下：
- 使用者通過手機淘寶來搜尋商品或者檢視寶貝詳情。
- 詳情/搜尋/推薦通過調用商品中心傳回商品的圖檔URL。
- 用戶端本地如果有該圖檔的緩存，則直接渲染圖檔，否則執行下一步。
- 從CDN L1回源圖檔，如果L1有該圖檔的緩存，則用戶端渲染圖檔，同時緩存到本地，如果L1沒有緩存，則執行下一步。
- 從CDN L2回源圖檔，如果L2有該圖檔的緩存，則用戶端渲染圖檔，同時CDN L1及用戶端緩存圖檔内容，如果CDN L2沒有緩存該圖檔，則執行下一步。
- 從圖檔空間回源圖檔，圖檔空間會從OSS拉取圖檔源檔案，按要求進行尺寸縮放，然後執行編解碼，傳回用戶端能夠支援的圖檔内容，之後用戶端就可以渲染圖檔，同時CDN的L1、L2以及用戶端都會緩存圖檔内容。
頻繁換圖帶來的技術挑戰
當商品的價格發生變化時，我們會使用新的價格重新合成圖檔，更新商品中心中存儲的圖檔URL。這樣會帶來2個問題：
1、CDN及手機淘寶原本緩存的圖檔内容失效了，使用者通路圖檔會全部回源到img-picasso。
2、由于更改了商品的字段，交易的核心應用（購物車和商品中心）的緩存也失效了，使用者浏覽及購物時，對商品的通路會走到db。
源站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個辦法：
1、改圖保持圖檔URL不變，可以避免商品鍊路的緩存失效。
2、在通路高峰到來之前，提前預熱圖檔到CDN，可以避免CDN緩存失效對源站的壓力。
下面，介紹下我們具體是怎麼做到這2點的。
頻繁換圖的應對方案
▐ 改圖保持圖檔URL不變
圖檔内容發生變化時，執行下面2個操作：
1、更新OSS内容：使用新的圖檔内容替換OSS中老的圖檔内容
2、重新整理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個原因：
1、圖檔完整的連結太長，是以存儲時經常隻存最後一段，業務自己來拼域名，很多業務就自己申請了一個圖檔域名來拼。
2、PC時代，浏覽器對同一域名下的并發請求數是有限制的，不同浏覽器不一樣，一般6個左右。為了突破該限制，一些業務就會申請多個域名，随機的拼不同的域名。
前面我們講過，CDN的緩存是跟域名綁定的，不管是緩存命中還是緩存清除，都隻能針對一個域名。
我們顯然不可能改一張圖，就去對300個域名調用CDN重新整理。于是我們考慮對圖檔域名進行收斂，使得使用者對圖檔的通路都路由到同一個域名，我們希望将所有的圖檔通路統一收斂到picasso.alicdn.com，具體實作方式如下：
1、對于手淘和貓客用戶端，圖檔通路都收口在圖檔庫，我們推進圖檔庫進行改造，符合一定規則的url，統一收斂到picasso.alicdn.com，實作了域名的一刀切。
2、對于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緩存的方式實作。
總結和展望
CDN技術廣泛應用于網際網路的各個場景，如今的CDN服務商，都提供了非常簡單的業務接入方式，而且CDN的費用每年都在降低，這一切使得CDN的接入和使用成本越來越低。
本文通過淘寶圖檔業務的例子，為大家闡述了使用CDN過程中可能遇到的問題和解決思路。
淘寶的圖檔業務除了通路量大，還會面臨更新頻繁的問題。圖檔的頻繁更新，一方面會由于商品上的圖檔url變化，導緻商品緩存失效，另一方面會大幅降低CDN的圖檔通路緩存命中率。
針對圖檔url變化導緻商品緩存失效的問題，我們通過重新整理cdn緩存，使用者通路時重新回源的方式，實作了改圖保持圖檔url不變，這個過程中了，我們解決了一些列的問題，包括：OSS三地同步更新、圖檔尺寸收斂、圖檔域名收斂、用戶端及浏覽器本地緩存。
針對改圖降低CDN圖檔緩存命中率的問題，我們根據業務的特點，提前合成不同波段的圖檔，并預熱到CDN，保障了源站的安全。
目前，淘寶上使用者看到的圖檔，都是提前合成好的。未來，我們考慮在使用者通路圖檔時，實時合成圖檔。通過這項技術，可以實時感覺業務更多的實時資訊，可以根據這些資訊，在圖檔上合成目前使用者或者環境更比對的文案/元素等内容，給使用者帶來更多的驚喜。
當然，實時合圖也會面臨更多的挑戰，如：計算能力、合圖性能。此外，對于CDN而言，由于每次使用者通路的内容是臨時合成的，CDN的緩存政策也是一個很大的挑戰。
淘系技術部-鹿班團隊-誠招英才
技術來驅動業務！！！淘系技術部鹿班團隊，長期聚焦在圖檔及視訊領域，通過技術創新，提升商家的經營效率及使用者的體驗，如果你對圖檔或者視訊技術感興趣，或者希望接觸到高并發的工程系統，希望通過code改變世界，歡迎加入我們！！！[email protected]
關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~