1.當某個頁面訪問量很大時，而且涉及到商品名稱、商品顏色尺碼等改動不大的資料(可以儲存在redis集群)時，對於這些資料，可以建立乙個後台管理 系統，
例如後台修改商品後台系統後，通過mq訊息通知，修改redis中相應的資料；
對於熱門商品 （資料量不大），可以存放到jvm記憶體中，
這樣當訪問量很大時，如果是熱門商品 ，從記憶體中讀取資料很快，如果不是熱門資料，從redis集群中讀取，也不慢，減少資料庫的壓力
2.讀多寫少，資料庫採用一主一備，多從庫，讀寫分離(通過mysql-proxy實現負載均衡),主備間通過mysql replication實現，主從庫間通過hash演算法實現
當主庫從庫都扛不住壓力時(不可能一直增加從庫，這樣主庫從庫之間資料同步複製開銷增大)，可以根據業務拆分資料庫，分庫分表
或者先寫快取，再非同步寫回db，或者限流
3.對於熱點、靜態html頁面，甚至可以部署在cdn快取伺服器上，根據 cdn就近伺服器原則，請求定位到離使用者最近的伺服器上，減少服務響應時間
4.如果頁面商品很多，而且訪問量大，可以根據商品編號，對%n取模，這樣可以根據商品編號定位到不同伺服器上(當然儲存到伺服器上也要採用前面相同的演算法),這樣可以減少訪問時間(有點類似分庫分表)
5.對於庫存資料，可以儲存在本地記憶體中，定期從cache讀取，影響是加入購物車顯示有貨，但是提交訂單時，訂單系統會對庫存做強校驗，影響不大
6.某些服務例如黑白名單/實時資料統計/ab測試，可以通過nginx+lua+redis實現，防止請求到應用伺服器
高併發解決方案 java專案
高併發解決方案 請求 nginx tomcat web應用 底層service 資料庫 請求到nginx，nginx到tomcat，乙個網域名稱可以配置多個ip或者配置不同的埠，通過加權輪詢的方式，訪問不同的伺服器，負載均衡 應用訪問service可以使用dubbo，註冊多個服務，訊息佇列來解決併發...
高併發解決方案
時常看到高併發的問題，但高併發其實是最不需要考慮的東西。為何，他虛無縹緲，很少有 真的需要這些東西，而且其中很多技術，其實你已經在用了。有這個意識就夠了，不需要時刻盯著這個問題。只有很少的 真的能達到高併發。簡單做乙個歸納，從低成本 高效能和高擴張性的角度來說有如下處理方案 1 html靜態化 2 ...
高併發解決方案
將靜態資源分離到靜態站，對靜態資源的請求打到靜態站，增加動態站的請求處理量 頁面靜態化是將程式生成的頁面儲存起來，使用模板技術如freemarker和velocity生成靜態頁面 nginx快取頁面資訊，再次請求時直接從快取中獲取，不需要重新生成，頁面快取記憶體中，提高訪問速度 具有相同處理功能的伺...