最近看了很多高併發的解決方案，高併發並沒有通用的解決方案，也不會有現成的demo或者原始碼可以參考，我在這方面也沒有什麼經驗
但是從我看到很多深度不高的文章來說，可以總結出一些可以真正落地的解決辦法
1.入口流量分發，軟體硬體分發
常見的nginx**負載均衡，lvs虛擬ip流量分發，以及f5硬體負載均衡
nginx負載均衡實際上是使用http**來實現的，流量是先進入nginx伺服器，然後請求後方應用伺服器，應用伺服器返回資料給nginx，nginx再輸出給使用者
nginx負載均衡效果大部分取決於nginx伺服器的效能，一般能應付一萬左右併發量
lvs 除了dr模式效能比較好之外，其他模式效能並沒很大提高，其主要實現原理是修改請求報文（網路4層）中的mac位址，將請求傳送到真實伺服器
lvs 與rs伺服器必須在同乙個網段內才能實現最好的效果，並且無法感知rs伺服器是否正常訪問
通常使用lvs負載到nginx伺服器，nginx伺服器能獲取應用的可用狀態，從而實現高可用
2.頁面靜態化，前端cdn快取
對於一些更新不是很頻繁的頁面，可用通過運維人員設定的定期計畫任務，生成靜態頁面，然後提交到nginx伺服器上，讓nginx去處理靜態請求
前端js，css，images等資源打包，實現前後端分離，並按照hash定義為版本號，放置到cdn快取伺服器上，加快處理與響應速度，減少應用伺服器負擔
3.服務切分，應用集群
將業務拆分成多個服務，並按照服務的負載量來伸縮部署應用，負載高的就部署多一些，在特殊情況下，可用關閉一些不重要的服務來維持主要業務的處理
4.訊息佇列，任務佇列
應對突發高併發情況，任務不能立即處理完成，此時建立訊息佇列，有專門的服務處理這些佇列，完成後再通知應用伺服器，應用伺服器再返回結果給使用者
5.流量限制與服務降級
在佇列超過一定數量，請求量超過伺服器處理能力的情況下，給使用者返回 失敗/預設內容/快取資訊/引導到上級頁面，從而保證業務的正常執行
6.應用自身快取，分布式快取
對於頻繁操作的資料，或者計算量大的資料，可用將資料存放到快取中
7.資料庫分表分庫，讀寫分離
根據業務或者資料量，將資料庫拆分成多個表和多個庫，按照 資料量/資料id/使用者id 來將資料儲存到具體的庫與表中
讀取的時候從多個表和資料庫裡面獲取資料，然後合併到一起返回
資料庫按照讀寫分離為主庫和從庫，主庫主要負責資料更新寫入，從庫負責同步資料和讀取資料，對讀多寫少的場景效果比較好
從庫同步是需要時間的，並不能寫入後馬上讀取從庫，解決方法目前我也想了一些，不過並不成熟
高併發處理思路與手段（五） 應用限流
限流不能亂用，否則正常流量會出現一些奇怪的問題，從而導致使用者抱怨。假設有130w到140w的資料插入到資料庫中，如果沒有做限流，資料庫的主庫會突然接收到130w的插入操作。首先是網路上的開銷，很可能直接把頻寬佔滿，導致其他請求無法正常傳輸和處理，其次會是資料庫的負載突然增高，導致無法處理某些資料庫...
高併發的處理
前幾天面試的時候被人問到，關於高併發的處理。無奈自己只知道從sql語句和表分割槽索引，靜態頁，快取等優化。其他的優化方法不了解。今天搜尋了下資料，找到幾種解決方案。1 html靜態化 2 伺服器分離 3 資料庫集群和庫表雜湊 4 快取 5 映象 6 負載均衡 乙個典型的使用負載均衡的策略就是，在軟體...
處理高併發
這個我感覺都不是做開發來考慮的，但是估計面試需要。做查詢的時候會對查詢的表加上共享鎖。做更改的時候對錶加排它鎖。這個進行多個表更新查詢的時候x需要加鎖abc，y加鎖cba。現在x加了a需要c，y加了c需要a，就形成死鎖了。可以對錶建立乙個臨時表，臨時表不需要加鎖。還可以通過建立檔案組，來處理高併發，...