什麼是高併發
日常招聘為啥總是強調要有高併發的處理能力，因為這是大廠高級工程師必備的能力之一。
所謂的高併發，通常來講就是併發訪問，同時處理大量的請求。典型的例子就是天貓淘寶的雙十一，嗯，還有大家天天在刷高鐵票的12306。但是，究竟到什麼級別才算高併發呢，我們先來看兩個相關的概念：
TPS(QPS)：服務器每秒處理的事務總數；
響應時間：處理一個請求的總共消耗的時間。
通常情況下，一個請求消耗的CPU、I/O資源越多，系統的併發能力就越差。
場景分析
假設我們網站一個請求的響應時間是200ms，服務器使用多進程的網絡模型，也就是單個進程每秒能處理5個請求，此時進程數越多，併發能力就越強，當然，必須是在系統能夠正常處理的範圍內。如果我們同時開啟1000個進程，那麼這臺服務器每秒就能處理5000個請求。
公司規模較小時，單臺服務器便可以很好應付日常的請求，但是隨著公司的發展，網站需求的變更，頁面的響應時間越來越慢，此時就到了需要優化的時候了。也許很多人會直接說，換更好的服務器，但是，想一想，能用錢解決的問題那還叫問題嗎。
優化併發能力
在服務器資源一定的情況下，優化單個請求的響應時間就成了唯一的選擇。此時我們就需要找出程序中最耗時的部分進行優化，比如卡在程序本身，那麼我們就優化程序，如果是卡在數據庫查詢的環節，那麼我們就需要優化數據庫查詢，甚至使用內存緩存也是可以的。如果能將單個請求的耗時降低至20ms以內，那麼在理想的情況下，系統的併發能力就可以提升10倍，為什麼說是理想情況，因為系統的併發能力還受到其他因素的制約，比如系統內存，I\O。
如果程序本身已經優化到極致，依然無法應對大量的請求，那麼就提升機子的性能，如果還不行，那麼就應該考慮進行系統的水平擴展了，比如我們經常使用的負載均衡策略，水平擴展服務器，增加系統的併發能力。
後記
作為一個開發者，要想處理好高併發的問題，就需要思考：
代碼已經最優，有沒有性能問題；
整體的架構是否合理；
數據庫設計是否合理；
有沒有合理使用內存。
閱讀更多 架構之美 的文章
