java緩存技術(shù)在網(wǎng)站的應(yīng)用
推薦 + 挑錯(cuò) + 收藏(0) + 用戶評(píng)論（0）
Web 開發(fā)中，接口會(huì)被分為以下幾類：
1.純靜態(tài)頁面。打死我都不會(huì)修改的頁面。很長一段時(shí)間內(nèi)，基本上不會(huì)修改。比如：關(guān)于我們。
2.純動(dòng)態(tài)頁面。實(shí)時(shí)性，個(gè)性化要求比較高。頁面變化很大，或者每個(gè)用戶看到的都不一樣，比如：朋友圈。
3.短時(shí)靜態(tài)頁面。在一定時(shí)間內(nèi)基本不會(huì)變化，或者是容忍不需要實(shí)時(shí)更新。比如：文章、新聞。
4.動(dòng)靜結(jié)合頁面。這個(gè)頁面既有動(dòng)態(tài)，也有靜態(tài)內(nèi)容。也是實(shí)際應(yīng)用中最多的。
對(duì)于以上類型的頁面，可以做不同的緩存方案。各位大神們應(yīng)該根據(jù)自己業(yè)務(wù)
的情況，靈活調(diào)整緩存方案。以下內(nèi)容可以作為參考。
模板渲染
高速發(fā)展的模板引擎，給前端渲染帶來了活力。Mustache、jade、hbs 靈活的模板語法讓頁面開發(fā)變得更省力和高效。
HtmlDOM == VeiwEngine.render（template ，data）;
瀏覽器只認(rèn)識(shí) DOM 結(jié)構(gòu)的字符串，也就是常說的 HTML5 格式。對(duì)于前端來渲染 DOM，還是后端渲染的問題，在此不用討論，為了情況前端的性能和體驗(yàn)，后端渲染會(huì)更合適。對(duì)于同一個(gè)頁面，每次請求都會(huì)產(chǎn)生一次渲染嗎？渲染總是要計(jì)算的，這樣多浪費(fèi)服務(wù)器性能啊！確實(shí)是這樣，除非你用了緩存。
頁面緩存的方案
1. 純靜態(tài)頁面
直接放 CDN。純靜態(tài)頁面的訪問量一般不會(huì)很大，程序直接響應(yīng)也是可以的。
2. 純動(dòng)態(tài)頁面
都說是動(dòng)態(tài)頁面了，那就不要做頁面緩存了。可以考慮做數(shù)據(jù)緩存，或者是 redis、DB 緩存。
3. 短時(shí)靜態(tài)頁面
a. 服務(wù)器端文件緩存
請求--》處理接口--》 模板渲染 ---》 存儲(chǔ)文件---》 響應(yīng)文件
緩存動(dòng)態(tài)頁面，你也可以把生成的文件存到 CDN，然后讓 CDN 去響應(yīng)請求。如果你的請求需要過一些驗(yàn)證，那就把文件存儲(chǔ)到服務(wù)器，由業(yè)務(wù)服務(wù)器去響應(yī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è)文件要不要備份呢？
b. Redis Cache
請求--》 接口接口---》 模板渲染 --》 存儲(chǔ)數(shù)據(jù)--》 響應(yīng) DOM
把請求的 url 當(dāng)做 key，把模板渲染好的數(shù)據(jù)當(dāng)做值，然后根據(jù)緩存規(guī)則，把數(shù)據(jù)存儲(chǔ)到 redis。
這種小成本的緩存在我們的系統(tǒng)中有實(shí)踐，的確大幅提高了系統(tǒng)的響應(yīng)時(shí)間和 QPS，頁面的請求大部分是從 redis 讀數(shù)據(jù)，然后返回，單機(jī)測試過極限性能，14k QPS。簡單描述一下。我們稱之為靜態(tài)化staticize
開始請求
請求校驗(yàn)，filter 等等
查詢緩存 redis
如果有緩存，則直接響應(yīng)
沒有緩存，查詢數(shù)據(jù)，重新渲染，存儲(chǔ)到 redis.
響應(yīng)
如果需更新緩存，只需要?jiǎng)h掉對(duì)應(yīng)的redis 值
4. 動(dòng)靜結(jié)合的頁面
這種頁面在實(shí)際情況中更常見。原則：靜態(tài)頁面緩存，動(dòng)態(tài)部分異步請求。
靜態(tài)部分也是模板渲染過來的，瀏覽器會(huì)從 CDN 或者后臺(tái)緩存中獲取到靜態(tài)頁面。頁面響應(yīng)的時(shí)間和瀏覽器的渲染會(huì)直接影響用戶體驗(yàn)。動(dòng)態(tài)更新的部分一般會(huì)在一些細(xì)節(jié)部分，比如頁面的登錄狀態(tài)。對(duì)于所有用戶來說，我看到的這個(gè)頁面，只有用戶頭像部分會(huì)不一致。如果系統(tǒng)為每個(gè)用戶生成一個(gè)靜態(tài)頁面成本就太高了，而且完全沒必要。
這個(gè)頁面就變成了：頁面 == 短時(shí)靜態(tài)頁面 + 局部動(dòng)態(tài)頁面。
『用戶狀態(tài)信息』這個(gè)特殊的動(dòng)態(tài)內(nèi)容，還需要用到本地的緩存機(jī)制。用戶在切換頁面的時(shí)候，每個(gè)頁面都需要?jiǎng)討B(tài)加載用戶信息，所以我們的做法是在第一次請求到這個(gè)信息的時(shí)候，存儲(chǔ)到 localStorage，然后設(shè)置過期時(shí)間。退出的時(shí)候，主動(dòng)清理 localStorage。
比如：個(gè)性化，個(gè)人推薦這種因人而異的板塊都可以做成局部動(dòng)態(tài)頁面的形式。
5. 數(shù)據(jù)緩存
以上的方案同樣適用于異步請求。
對(duì)于CDN 或者其他緩存來說，緩存不知道你存的內(nèi)容是 DOM 還是 JSON，還是其他格式。它只是幫你存儲(chǔ)數(shù)據(jù)。你同樣可以的把，數(shù)據(jù)接口、局部 DOM 結(jié)構(gòu)（非完整 html 格式）存儲(chǔ)到 CDN 或者是 redis 中。比如：頁面的配置信息，或者從相關(guān)推薦系統(tǒ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)行刪除操作
非常好我支持^.^
(0) 0%
不好我反對(duì)
(0) 0%