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