前言：
我們知道nginx+tomcat可以實現動靜分離，但這並不是最好的解決方案，因為往往頻寬會成為瓶頸。
分析**訪問慢的真正原因？
很多情況下往往是靜態資源太大，而頻寬不足，導致**載入很慢。
解決方案:
一、 cdn內容分發（解決頻寬不足）
使用第三方oos（物件儲存），如七牛雲，阿里雲oos等
二、 減少與服務端的頻寬傳輸（解決靜態資源太大）
1. 靜態資源手動壓縮
2. 使用nginx靜態資源壓縮
原理：使用nginx配置：字典匹配，例如：nginx將js檔案中的function根據一定演算法替換成a，瀏覽器拿到a過後，通過字典查詢a就是function，這樣就減少了檔案中需要儲存的字元，其中的實現過程我們並不需要關心。缺點：相對於自己手動壓縮，nginx壓縮相對比較耗費cpu和記憶體資源；壓縮也會越壓縮越模糊。
3. 大分段拆分
大我們通常會採取壓縮，但是壓縮後還是很大，而且變得很模糊，不推薦。4. 瀏覽器靜態資源版本控制我們可以通過ps等影象處理工具
將拆分成多段，例如**商品的詳情頁，看起來像一張圖，但是實際上是很多張通過瀏覽器可以非同步載入，提高網頁響應速度。
另外一篇blog專門介紹了：靜態資源使用時間戳控制瀏覽器快取5. 使用nginx快取靜態頁面思想瀏覽器快取原理：http狀態碼 304 第一次請求會將內容快取，第二次請求會響應304表示使用本地快取。
更新伺服器靜態資源檔案的修改時間，瀏覽器發現最後修改時間大於快取檔案的時間，則使用伺服器資源。靜態資源請求url上
加時間戳引數
需要考慮的問題：redis與資料庫一致性問題（mq訂閱blog日誌實現 同步資料一致性問題）
jvm與redis快取一致性問題
nginx快取與伺服器端真實快取的一致性問題 （1. 刪除nginx快取；2.商品詳情表加版本號字段，詳情請求加上版本引數； 3.lua語言動態渲染模板，控制nginx本地快取）
實戰，使用nginx快取商品詳情頁面？
nginx核心配置：
##如果是以all開頭只做反向**不快取到nginx中
location /all
##如果是以快取開頭的話，快取到nginx中
location /details
刪除nginx快取，不推薦；
商品詳情表加版本號字段，詳情請求加上版本引數；
lua語言動態渲染模板，控制nginx本地快取
高併發實戰
參考書籍netty,redis,zookeeper高併發實戰 作者 尼恩 鏈結 netty是jboss提供的乙個j a開源框架,是基於nio的客戶端 伺服器程式設計框架,它既能開發高併發,高可用,高可靠性的網路伺服器程式,也可以開發高可用,高可靠的客戶端程式 乙個可以快速儲存的記憶體資料庫,redi...
IDea和nginx解決高併發
1 order user系統高併發結構 1.1高併發？網際網路專案，一般必須支援高併發，我們開發的order user系統支援多少併發 單位時間併發 取決於系統執行使用的web容器 tomcat 取決於系統伺服器的硬體。tomcat併發 一秒鐘200 500左右，所以不支援高併發！所以單機執行ord...
高併發解決方案 頁面靜態化
一 什麼是頁面靜態化 簡 單的說，我們如果訪問乙個鏈結 伺服器對應的模組會處理這個請求，轉到對應的jsp介面，最後生成我們想要看到的資料。這其中的缺點是顯而易見的 因為每次請求伺服器都會進行處理，如 果有太多的高併發請求，那麼就會加重應用伺服器的壓力，弄不好就把伺服器 搞down 掉了。那麼如何去避...