高併發伺服器邏輯處理瓶頸，如何解決？首先我們先了解什麼是併發！
併發，在作業系統中，是指乙個時間段中有幾個程式都處於已啟動執行到執行完畢之間，且這幾個程式都是在同乙個處理機上執行，但任乙個時刻點上只有乙個程式在處理機上執行。———**《百科》顧名思義，高併發就是在指定時間內，系統同時能夠處理大量的請求（連線數）。那麼如何衡量高併發呢？高併發衡量指標
吞吐量：單位時間內處理的請求數量；
qps（tps）：每秒可以處理的請求數或事務數；
併發使用者數：同時承載正常使用系統功能的使用者數量，即多少人同時使用，系統還能正常執行的使用者數量；
根據上面衡量指標可以看到，提高併發能力必須解決如下幾個問題：
如何提高併發連線數？
那麼多的連線數怎麼進行業務處理？
應用伺服器的處理水平又該怎麼提高？
如何使用微服務架構提公升高併發邏輯？
別著急，這麼多問題我們乙個乙個來分析解決！
如下圖所示，常規的單一網路連線模型只能1個連線對應1個執行緒，壓力都集中在記憶體，導致記憶體開銷非常大，肯定支撐的連線數有限！（直接掛掉）
單一網路連線模型
有道是業務寫的再好不如一台高效能伺服器，這個鍋不一定要開發人員背的哦！！！伺服器的連線入口就那麼大（比如tomcat只有幾千的連線數），那麼處理的能力也只侷限於幾千。
怎麼解決呢？選用合適的網路io模型或者selector，通過使用乙個執行緒輪詢或者事件觸發的方式，能支援幾萬甚至更多的連線數，再配合上nginx做負載就更完美了。
大家都知道nginx只是具有反向**和負載均衡的功能，並不能處理具體的業務邏輯，不能擔當應用伺服器來使用。例如websphere 、tomcat和jetty等，但是我們可以利用nginx將接受到的大量連線通過均衡的方式（輪詢，權重，hash）分配到不同的應用伺服器中進行業務處理！
nginx負載
要提高應用伺服器的處理水平就要了解自己的應用伺服器的瓶頸在**，一般有兩個：
資料庫本身：建立有效索引、讀寫分離、雙主互備、分庫分表（sharding-jdbc等實現）等策略，提高資料庫處理能力，減少壓力！
結合記憶體資料庫：例如redid、memcached等，根據業務需要快取一些資料字典、列舉變數和頻繁使用資料等減少資料庫訪問次數，提公升資料庫處理能力。
web集群架構圖
如上圖web集群架構圖所示：
組成了經典的web高併發集群架構。
**中的業務邏輯：
開發中可以採用前後端分離的架構模式，動靜分離、松耦合等提公升前後端處理能力。
先看一下非常火的這張微服務架構圖：
微服務架構圖
主要包含11大核心元件，分別是：
核心支撐元件
資料匯流排kafka
出來上述幾點解決高併發伺服器邏輯處理瓶頸外，還要考慮網路因素，例如採用cdn加速，將不同地點的請求分發到不同的服務集群上，避免網路對速度的影響！
總之，根據自身實際業務在合理範圍內盡可能的拆分，拆分以後同類服務可以通過水平擴充套件達到整體的高效能高併發，同時將越脆弱的資源放置在鏈路的越末端，訪問的時候盡量將訪問鏈結縮短，降低每次訪問的資源消耗。服務之間直接restful模型使用http呼叫，或者redis，kafka類的訊息中介軟體通訊。單個服務直接使用nginx做負載集群，同時前後端分離，資料庫分庫分表等一整套分布式服務系統！
前後端分離
如何提高伺服器併發處理能力
以下內容為入門級介紹，意在對老技術作較全的總結而不是較深的研究。主要參考 構建高效能web站點 一書。一台伺服器在單位時間裡能處理的請求越多，伺服器的能力越高，也就是伺服器併發處理能力越強 吞吐率，單位時間裡伺服器處理的最大請求數，單位req s 從伺服器角度，實際併發使用者數的可以理解為伺服器當前...
高併發伺服器的設計 架構與瓶頸的設計GOOD
做架構設計，難免有時候被人問及系統的瓶頸在哪，那首先來了解下什麼是瓶頸？打個形象的比方,人的嘴巴可以吞下一整個麵包，但是卻嚥不下去，因為食管不給力，它比較細，所以嘴巴能吞下的食物大小要受到食管的粗細限制。城市內部每天會產生幾十萬件跨城快遞，可是跨城的交通不給力，只允許走小型卡車，一卡車一次就能裝幾千...
Epoll實現伺服器高併發
最近在做乙個關於高併發伺服器相關的專案需要用到非同步 非阻塞io通訊，實現高tcp併發。以下用epoll技術實現乙個簡單的tcp高併發伺服器，驗證無業務處理的情況下，epoll處理併發連線的數的效果。include include include include include include in...