花了2個小時思考和碼字，覺得錯誤的，可以摒棄；覺得正確的，可以採納；覺得還有更好的，希望能給出建議。
首先我們要理解什麼是“高併發”這個概念，“支撐”的概念主要是目的目標。很多小夥伴面試可能問到這個問題，一上來就說方法，用redis快取,資料庫優化，主從複製，分庫分表，還有什麼微服務...，相信講完，面試官可能說“哦~”完了。只講結果，沒去分析原因，人家很肯定知道你在背答案。這也能理解，我們平時很難有機會碰到高併發的專案。只要我們思考過，分析過，一定有所收穫。
什麼是“高併發”，我們可以從事物都是具有兩面性的特性出發。有高，就有低；有併發，也有沒併發。 低的時候我們的系統是如何的？高的時候我們的系統是如何的？如果低和高一樣的，那肯定完完了。“高併發”就是保證我們的系統高可用性，如同正常(無併發)訪問我們的站點一樣，提供優質可用服務。
分析“高併發”，我們就要知道目前離高併發的差距是什麼？剛才提到優質可用服務，提到高可用系統。在高可用系統的同時，可以能帶來很多問題，增加管理的複雜性。所以畫出系統圖來分析。
箭頭 + ：A 增強 B增強
箭頭 - ：A 增強 B減弱
所以高併發不是憑空來的，是我們的優質服務產生的，服務好帶來的流量大，這就要求我們保證我們系統高可用性，這樣才能帶來更多流量。但是什麼事情都有個上限，高可用可能帶來更多的裝置機器設施，增加了我們的管理上的複雜性等問題。但是這些都是保證高可用性支撐高併發要解決的問題和優化的地方。
管理方面涉及東西太多了，本身專案管理的範圍就已經夠大了。這裡不展開了。我們從高可用系統來分析下怎麼解決高併發問題。
我這裡從4個維度來展開，把它們有效的組合在一起形成了架構，如圖：
看到這張圖，大家可以集中注意力，怎麼組合搭配，想想大流量網站是如何搭配組合的？在組合有效的基礎上再進行作出方案。如果已經有組合的情況下(LNMP)我們可以去畫圖思考如何做好優化和執行方案。同時在業務的持續演進的時候保證系統的是否能支撐高併發以及系統高可用性。這裡只是從整體去觀察分析。具體怎麼實現，在社群裡面有很多同學給出了答案，沒有最好的，確實是可行的。
推薦閱讀：
你的系統如何支撐高併發？