全站緩存時代

Zhuxy 發(fā)布于2019-08-06 13:17 / 3350人閱讀

摘要：頁面緩存的方案純靜態(tài)頁面直接放。原則靜態(tài)頁面緩存，動態(tài)部分異步請求。靜態(tài)部分也是模板渲染過來的，瀏覽器會從或者后臺緩存中獲取到靜態(tài)頁面。

原則：動靜分離，分級緩存，主動失效。

Web 開發(fā)中，接口會被分為以下幾類：

純靜態(tài)頁面。打死我都不會修改的頁面。很長一段時間內(nèi)，基本上不會修改。比如：關于我們。

純動態(tài)頁面。實時性，個性化要求比較高。頁面變化很大，或者每個用戶看到的都不一樣，比如：朋友圈。

短時靜態(tài)頁面。在一定時間內(nèi)基本不會變化，或者是容忍不需要實時更新。比如：文章、新聞。

動靜結合頁面。這個頁面既有動態(tài)，也有靜態(tài)內(nèi)容。也是實際應用中最多的。

對于以上類型的頁面，可以做不同的緩存方案。各位大神們應該根據(jù)自己業(yè)務的情況，靈活調整緩存方案。以下內(nèi)容可以作為參考。

模板渲染

高速發(fā)展的模板引擎，給前端渲染帶來了活力。Mustache、jade、hbs 靈活的模板語法讓頁面開發(fā)變得更省力和高效。

HtmlDOM == VeiwEngine.render(template ,data);

瀏覽器只認識 DOM 結構的字符串，也就是常說的 HTML5 格式。對于前端來渲染 DOM,還是后端渲染的問題，在此不用討論，為了情況前端的性能和體驗，后端渲染會更合適。對于同一個頁面，每次請求都會產(chǎn)生一次渲染嗎？渲染總是要計算的，這樣多浪費服務器性能?。〈_實是這樣，除非你用了緩存。

頁面緩存的方案 1. 純靜態(tài)頁面

直接放 CDN。純靜態(tài)頁面的訪問量一般不會很大，程序直接響應也是可以的。

2. 純動態(tài)頁面

都說是動態(tài)頁面了，那就不要做頁面緩存了?？梢钥紤]做數(shù)據(jù)緩存，或者是 redis、DB 緩存。

3. 短時靜態(tài)頁面

1. 服務器端文件緩存

請求-->處理接口--> 模板渲染 ---> 存儲文件---> 響應文件

緩存動態(tài)頁面，你也可以把生成的文件存到 CDN，然后讓 CDN 去響應請求。如果你的請求需要過一些驗證，那就把文件存儲到服務器，由業(yè)務服務器去響應請求。文件還有一個好處是：流。例如：FileReadStream.pipe(ResponseStream)。響應的時候，不需要把文件的內(nèi)容加載到內(nèi)存，而是直接用 stream 的方式響應。但是弊端也不少，文件存儲，會有并發(fā)讀寫死鎖問題。

還有一個問題，分布式系統(tǒng)?？赡苣阌?A、B、C 三個服務器。A 服務器生成了一個文件，還需要實時同步到 B 和 C。當然也可以讓 A、B、C 掛載同一個磁盤。問題又來了，這個文件要不要備份呢？

2. Redis Cache

請求--> 接口接口---> 模板渲染 --> 存儲數(shù)據(jù)--> 響應 DOM

把請求的 url 當做 key，把模板渲染好的數(shù)據(jù)當做值，然后根據(jù)緩存規(guī)則，把數(shù)據(jù)存儲到 redis。

這種小成本的緩存在我們的系統(tǒng)中有實踐，的確大幅提高了系統(tǒng)的響應時間和 QPS，頁面的請求大部分是從 redis 讀數(shù)據(jù)，然后返回，單機測試過極限性能，14k QPS。簡單描述一下。我們稱之為靜態(tài)化staticize

開始請求

請求校驗，filter 等等

查詢緩存 redis

如果有緩存，則直接響應

沒有緩存，查詢數(shù)據(jù)，重新渲染，存儲到 redis.

響應

如果需更新緩存，只需要刪掉對應的redis 值

4. 動靜結合的頁面

這種頁面在實際情況中更常見。原則：靜態(tài)頁面緩存，動態(tài)部分異步請求。

靜態(tài)部分也是模板渲染過來的，瀏覽器會從 CDN 或者后臺緩存中獲取到靜態(tài)頁面。頁面響應的時間和瀏覽器的渲染會直接影響用戶體驗。動態(tài)更新的部分一般會在一些細節(jié)部分，比如頁面的登錄狀態(tài)。對于所有用戶來說，我看到的這個頁面，只有用戶頭像部分會不一致。如果系統(tǒng)為每個用戶生成一個靜態(tài)頁面成本就太高了，而且完全沒必要。

這個頁面就變成了：頁面 == 短時靜態(tài)頁面 + 局部動態(tài)頁面。

『用戶狀態(tài)信息』這個特殊的動態(tài)內(nèi)容，還需要用到本地的緩存機制。用戶在切換頁面的時候，每個頁面都需要動態(tài)加載用戶信息，所以我們的做法是在第一次請求到這個信息的時候，存儲到 localStorage，然后設置過期時間。退出的時候，主動清理 localStorage。

比如：個性化，個人推薦這種因人而異的板塊都可以做成局部動態(tài)頁面的形式。

5. 數(shù)據(jù)緩存

以上的方案同樣適用于異步請求。

對于CDN 或者其他緩存來說，緩存不知道你存的內(nèi)容是 DOM 還是 JSON，還是其他格式。它只是幫你存儲數(shù)據(jù)。你同樣可以的把，數(shù)據(jù)接口、局部 DOM 結構（非完整 html 格式）存儲到 CDN 或者是 redis 中。比如：頁面的配置信息，或者從相關推薦系統(tǒng)請求的 dom 結構。

緩存更新

一般會有主動失效和自動失效緩存機制。

CDN 和 redis 等緩存都可以根據(jù)規(guī)則設置緩存時間。緩存過期后，會再次獲取新的數(shù)據(jù)。
主動更新一般會用 API 調用方式實現(xiàn)。比如刪除 key,或者調用 CDN 接口進行刪除操作

緩存穿透

一般會在第一次請求的時候生成緩存，如果服務器端沒有緩存，然后在同一時刻出現(xiàn)高并發(fā)請求，請求會直接到達業(yè)務邏輯部分，很可能導致系統(tǒng)直接掛掉。

解決辦法：

主動創(chuàng)建緩存。緩存求由系統(tǒng)定時創(chuàng)建。

請求的時候設置標志位。第一個請求到達，標識這個 url 正在創(chuàng)建緩存，其他請求進入等待隊列。

全站 CDN 加速

CDN 動態(tài)加速如下圖所示：

例如我的網(wǎng)站有以下接口和頁面：

http://www.localhost.com/ // 短時緩存，動靜結合

http://www.localhost.com/api/user/1 // 純動態(tài)

http://www.localhost.com/post/hello-world // 永久靜態(tài)

所以，1、3頁面會放到 CDN，2 直接去源站請求。怎么做到呢？

在 CDN 配置自主源站。意味著請求 CDN 地址的時候，CDN 會去源站請求數(shù)據(jù)，然后緩存到 CDN 節(jié)點。

設置緩存規(guī)則

/ 緩存 1 分鐘
/post/* 緩存 1 年
/api/ 不設置緩存

cname www.localhost.com 到 CDN 提供的空間域名

多平臺 Mulit Origin

一個 URL 可能會在不同的平臺有不同的返回和表現(xiàn)形式。

產(chǎn)品的想法都是很完美，一個按鈕在不同的平臺會有不同的顯示狀態(tài)。實際情況非常復雜，在我們的系統(tǒng)中，出現(xiàn)過一個頁面出現(xiàn)在七個平臺，每個平臺的顯示效果會不一致。不管是模板渲染，或者是 js 處理按鈕狀態(tài)等等都是非常復雜的，或者 pc 和移動端頁面表現(xiàn)出樣式和結構差異。如果還要把這個頁面放到緩存，就更加復雜了。

為每個平臺生成一份緩存？可以！

平臺的識別來自 UserAgent，不同的瀏覽器或者 app，都有不同的UserAgent。不同的來源我們稱之為 Origin。Origin + url 就可以生成唯一的 key，去識別唯一的緩存。緩存不限于 redis 和文件緩存。

CDN 識別來源去讀取不同的文件，就需要 CDN 那邊做一些開發(fā)工作了。Upyun、七牛這邊暫時不支持的。BAT這種大公司他們自己維護的 CDN 就能完美地做到。

另一種思路：

1個項目，兩個域名，2個動態(tài) CDN。PC 和移動端頁面分離、接口共享。

例如：為同一個項目配置兩個域名：www.localhost.com 和 m.www.localhost.com，同時為這兩個域名各設置一個動態(tài) CDN。

由一項目提供兩個域名服務，比如：IndexController.main 處理請求 /homepage，移動端和 PC 端的請求路徑分別為

http://m.www.localhost.com/homepage

http://www.localhost.com/homepage

main action 會根據(jù)請求來源url，分別渲染不同的頁面。不同的域名頁面，也就被不同的動態(tài) CDN 緩存起來。

對于 /api/xxxx的接口，自然不需要做 PC 和移動端或者其他平臺的區(qū)分，一個 action 就可以解決了。這樣就避免了維護兩套系統(tǒng)的問題。

結語

以上，全站緩存基本完成。

不要憑空去拉高 QPS或者亂用緩存，根據(jù)你的業(yè)務和實際情況來對待。最重要的事情就是要牢記：保持簡潔，按需使用。

參考文獻

Upyun 自動動靜分離

天貓瀏覽型應用的CDN靜態(tài)化架構演變

靜態(tài)化

高性能服務器架構思路

云服務器 GPU云服務器全站全站cdn 全站靜態(tài)化 php全站

文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉載請注明本文地址：http://systransis.cn/yun/61801.html

全站緩存時代

摘要：頁面緩存的方案純靜態(tài)頁面直接放。原則靜態(tài)頁面緩存，動態(tài)部分異步請求。靜態(tài)部分也是模板渲染過來的，瀏覽器會從或者后臺緩存中獲取到靜態(tài)頁面。原則：動靜分離，分級緩存，主動失效。 Web 開發(fā)中，接口會被分為以下幾類：純靜態(tài)頁面。打死我都不會修改的頁面。很長一段時間內(nèi)，基本上不會修改。比如：關于我們。純動態(tài)頁面。實時性，個性化要求比較高。頁面變化很大，或者每個用戶看到的都不一樣，比如...

X1nFLY 2019-06-24 17:50 評論0 收藏0
全球HTTPS時代已來，你跟上了嗎？

摘要：而未來的互聯(lián)網(wǎng)網(wǎng)絡鏈路日趨復雜，加重了安全事件發(fā)生。蘋果強制開啟標準蘋果宣布年月日起，所有提交到的必須強制開啟安全標準，所有連接必須使用加密。最后是安全意識。互聯(lián)網(wǎng)發(fā)展20多年，大家都習慣了在瀏覽器地址里輸入HTTP格式的網(wǎng)址。但前兩年，HTTPS逐漸取代HTTP，成為傳輸協(xié)議界的新寵。?早在2014年，由網(wǎng)際網(wǎng)路安全研究組織Internet Security Research Gr...

hss01248 2019-06-21 16:30 評論0 收藏0
動靜內(nèi)容混合站點，怎樣用全站加速支持實際業(yè)務場景？

摘要：為了優(yōu)化動靜混合站點和純動態(tài)站點的加速效果，阿里云推出了全站加速方案，通過智能區(qū)分動靜態(tài)請求，實現(xiàn)整站加速效果的全面提升。摘要：伴隨著近幾年O2O的爆發(fā)，網(wǎng)絡已經(jīng)不僅是傳統(tǒng)的展示企業(yè)品牌的渠道，而逐漸演變成為嫁接企業(yè)和用戶之間服務和交流的橋梁，我們開始賦予網(wǎng)絡更多的功能，比如購物、出行、學習、娛樂等等。同時，網(wǎng)絡內(nèi)容形態(tài)的進階發(fā)展，網(wǎng)頁內(nèi)容已經(jīng)從靜態(tài)的圖片、文字向短視頻、直播演變...

sherlock221 2019-06-24 18:02 評論0 收藏0
專家觀點 | 新華三云計算架構師李遜：全融合企業(yè)級云解決方案

摘要：會上，新華三資深云計算架構師李遜發(fā)表了主題演講，介紹了新華三的全融合企業(yè)級云解決方案。新華三全融合企業(yè)解決方案，它做到全球化布局，可以為海油總部提供在線全站式云計算服務。近期第二屆浙江省云計算大數(shù)據(jù)產(chǎn)業(yè)推進大會在杭州舉行。會上，新華三資深云計算架構師李遜發(fā)表了主題演講，介紹了新華三的全融合企業(yè)級云解決方案。（以下內(nèi)容根據(jù)李遜在第二屆浙江省云計算大數(shù)據(jù)產(chǎn)業(yè)推進大會上發(fā)言整理。）新華三資深云計算...

xumenger 2019-04-29 19:22 評論0 收藏0
上海云棲：金融政企行業(yè)的CDN最佳實踐

摘要：摘要在剛剛結束的上海云棲大會飛天技術匯分論壇上，阿里云視頻云產(chǎn)品架構師羅小飛進行了阿里云面向金融政企的最佳實踐主題分享，為上海的嘉賓介紹的解決方案與技術服務體系。隨后，年阿里云宣布全面降價，打破了行業(yè)原有的價格不透明一客一價的模式。摘要：?在剛剛結束的上海云棲大會飛天技術匯分論壇上，阿里云視頻云產(chǎn)品架構師羅小飛進行了《阿里云CDN——面向金融政企的CDN最佳實踐》主題分享，為上海的嘉...

Kahn 2019-06-24 18:04 評論0 收藏0