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

原則：動(dòng)靜分離，分級(jí)緩存，主動(dòng)失效。

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

純靜態(tài)頁(yè)面。打死我都不會(huì)修改的頁(yè)面。很長(zhǎng)一段時(shí)間內(nèi)，基本上不會(huì)修改。比如：關(guān)于我們。

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

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

動(dòng)靜結(jié)合頁(yè)面。這個(gè)頁(yè)面既有動(dòng)態(tài)，也有靜態(tài)內(nèi)容。也是實(shí)際應(yīng)用中最多的。

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

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

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

瀏覽器只認(rèn)識(shí) DOM 結(jié)構(gòu)的字符串，也就是常說的 HTML5 格式。對(duì)于前端來渲染 DOM,還是后端渲染的問題，在此不用討論，為了情況前端的性能和體驗(yàn)，后端渲染會(huì)更合適。對(duì)于同一個(gè)頁(yè)面，每次請(qǐng)求都會(huì)產(chǎn)生一次渲染嗎？渲染總是要計(jì)算的，這樣多浪費(fèi)服務(wù)器性能??！確實(shí)是這樣，除非你用了緩存。

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

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

1. 服務(wù)器端文件緩存

請(qǐng)求-->處理接口--> 模板渲染 ---> 存儲(chǔ)文件---> 響應(yīng)文件

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

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

2. Redis Cache

請(qǐng)求--> 接口接口---> 模板渲染 --> 存儲(chǔ)數(shù)據(jù)--> 響應(yīng) DOM

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

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

開始請(qǐng)求

請(qǐng)求校驗(yàn)，filter 等等

查詢緩存 redis

如果有緩存，則直接響應(yīng)

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

響應(yīng)

如果需更新緩存，只需要?jiǎng)h掉對(duì)應(yīng)的redis 值

這種頁(yè)面在實(shí)際情況中更常見。原則：靜態(tài)頁(yè)面緩存，動(dòng)態(tài)部分異步請(qǐng)求。

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

這個(gè)頁(yè)面就變成了：頁(yè)面 == 短時(shí)靜態(tài)頁(yè)面 + 局部動(dòng)態(tài)頁(yè)面。

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

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

以上的方案同樣適用于異步請(qǐng)求。

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

一般會(huì)有主動(dòng)失效和自動(dòng)失效緩存機(jī)制。

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

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

解決辦法：

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

請(qǐng)求的時(shí)候設(shè)置標(biāo)志位。第一個(gè)請(qǐng)求到達(dá)，標(biāo)識(shí)這個(gè) url 正在創(chuàng)建緩存，其他請(qǐng)求進(jìn)入等待隊(duì)列。

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

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

http://www.localhost.com/ // 短時(shí)緩存，動(dòng)靜結(jié)合

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

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

所以，1、3頁(yè)面會(huì)放到 CDN，2 直接去源站請(qǐng)求。怎么做到呢？

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

設(shè)置緩存規(guī)則

/ 緩存 1 分鐘
/post/* 緩存 1 年
/api/ 不設(shè)置緩存

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

一個(gè) URL 可能會(huì)在不同的平臺(tái)有不同的返回和表現(xiàn)形式。

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

為每個(gè)平臺(tái)生成一份緩存？可以！

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

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

另一種思路：

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

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

由一項(xiàng)目提供兩個(gè)域名服務(wù)，比如：IndexController.main 處理請(qǐng)求 /homepage，移動(dòng)端和 PC 端的請(qǐng)求路徑分別為

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

http://www.localhost.com/homepage

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

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

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

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

Upyun 自動(dòng)動(dòng)靜分離

天貓瀏覽型應(yīng)用的CDN靜態(tài)化架構(gòu)演變

靜態(tài)化

高性能服務(wù)器架構(gòu)思路