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