小型電商網站的商品詳情頁的頁面靜态化架構以及其缺陷
背景是商品詳情頁的系統架構，以此基礎講解 -> 緩存架構 -> 高并發 -> 高可用
電商網站裡，大概可以說分成兩種，
- 小型電商，簡單的一種架構方案，頁面靜态化的方案；
- 大型電商，複雜的一套架構
為了講解大型電商的詳情頁架構，這裡先把小型的講解下
部分頁面靜态化或全量的頁面靜态化
先來看看頁面靜态化帶來的問題，假設有一個商品詳情頁的模闆如下
<html>
<title></title>
<body>
商品名稱：#{productName}
商品價格：#{productPrice}
商品描述：#{productDesc}
</body>
</html> 裡面的占位文法需要資料來填充，比如儲存在 mysql 中的，此時資料變化了或者模闆變化了，都需要重新渲染成 html 頁面，放在 nginx 上，供使用者通路。如果隻是某一個商品資料變化了隻影響了一個頁面那還好說，直接重新渲染這一個即可，但是有商品推薦的，可能其他商品詳情頁面裡面也會出現。這個時候就比較難判定了，可能隻會全量渲染了
那麼問題來了，對于小網站，頁面很少，很實用，非常簡單，使用的模闆引擎有 velocity、freemarker 等，頁面資料管理的 cms 系統，内容管理系統等做一個一鍵全量渲染功能即可
對于大型網站來說，比如淘寶，他們的商品資料太多了，根本就沒有這麼多的時間去重新渲染，上億的商品等，可能需要好幾天
大型電商網站的異步多級緩存建構 + nginx 資料本地化動态渲染的架構
大型電商網站的詳情頁架構一般是這樣的核心思路，如上圖
兩個關鍵點：
- 緩存資料生産服務
- nginx 上的 html 模闆 + 本地緩存資料
來捋一捋流程：
-
使用者通路 nginx
會先從 nginx 的本地緩存擷取資料渲染後傳回，這個速度很快，因為全是記憶體操作。 本地緩存資料是有時間的，比如 10 分鐘
-
假如 nginx 本地緩存失效
會從 redis 中擷取資料回來并緩存上
-
假如 redis 中的資料失效
會從緩存資料生産服務中擷取資料并緩存上
-
緩存資料生産服務
本地也有一個緩存，比如用的是 ehcache 他們通過隊列監聽商品修改等事件，讓自己的緩存資料及時更新
-
其他服務
商品、店鋪等服務能擷取到商品的修改事件等，及時往 mq 中發出商品的修改事件， 并提供商品原始資料的查詢。這裡可能是直接從 mysql 庫中查詢的
這樣一來，在緩存上其實就擋掉了很多資料，一層一層的擋并發