這篇文章對很多沒有高併發經驗的程式設計師來說，會非常有幫助。
很多程式設計師可能都遇到過類似的困惑：
我沒有高併發專案經驗，但是面試的時候經常被問到高併發、效能調優方面的問題，該怎麼辦？
今天給大家說一自己學習高併發的方法。
你可以自己寫一個小的電商專案，建議最簡單的單體結構的電商專案即可。
從最簡單的單體專案開始，然後按照以下三個階段來學習高併發。
第一階段
在高併發條件下，學習對單機效能優化。
用 Docker 容器去執行電商專案，然後用 jmeter、wrk 等工具去壓測。
在壓測期間，你會發現：由於系統每個模組不同，所以效能表現就不一樣。
這是正常的，不同模組、不同產品對併發指標的要求本身想·是不一樣的。例如，商品瀏覽和下訂單，一個讀為主，一個寫為主。
基於這種情況，你最好要編寫複雜的壓測指令碼，能自動實現不同模組的壓測任務。
然後在這種不斷地壓測探測下，去探測問題，並且通過優化程式碼、JVM 去解決問題。
比如，解決誤用 HashMap 導致死迴圈的問題。又比如，誤用不帶快取的檔案 IO 流，去讀取檔案的問題等等。
在程式和 JVM 優化完畢後，你可能又會發現資料庫也存在問題。於是，你又要去研究如何優化資料庫 SQL，如何對資料庫分表等問題。
也是在這個階段，你可能還會學的到，快取的必要性以及同步快取資料狀態的重要性等重要知識點。
在搞了單機優化後，沒有辦法再通過單機的壓測學到什麼新的東西了。於是，轉向第二階段。
第二階段
從阿里雲買了兩臺機器，開始嘗試使用負載均衡去分擔高併發的壓力。
同樣的，也是藉助壓測工具去模擬了高併發。在壓測期間，負載均衡和系統屢屢出現和單機完全不一樣的問題。
比如，負載均衡本身的效能問題。比如，在一些時候，負載均衡後面的機器負載是不平衡的，需要對負載演算法進行調整。
這個階段，你會接觸到負載均衡中大部分的細節。
但是，高併發中，很多系統的構成會很複雜，以至於需要分散式架構系統的程度。他們需要各種中介軟體做通訊，做儲存。
所以，繼續第三階段的練習。
第三階段
為了能熟悉市面上各中介軟體的使用，開始對單體的電商平臺進行改造。
比如，一些本地呼叫的方法，替換成 Dubbo 遠端呼叫。
比如，一些模組間呼叫，替換成 MQ 中介軟體傳訊息。
再比如，一些放在關聯式資料庫的被頻繁訪問的資料，改存在 MongoDB 中……
當然，壓測依然繼續。就這樣，你可以實踐到很多中介軟體和分散式框架的使用。
在模擬高併發練習的同時，別忘了去讀各種高併發高效能的書籍。比如，《大型網站伺服器容量規劃》、《網際網路創業核心技術：構建可伸縮的web應用》等書籍。
三個階段的學習之後，面試的大部分基礎問題你基本可以應付了。
畢竟在程式設計師這個圈子，90% 以上的人可能都沒有真正的高併發經驗。作為面試官來說：
為什麼我們需要找有高併發經驗的人？
說白了，我們想找的程式設計師其實是：
- 不會亂寫效能很差的程式碼
- 能敏銳感知到影響系統的問題
- 能獨立的處理由於高併發引發的問題
我們找熟悉高可用的人，其實並不要求這個人一定能給出什麼獨特的高可用方案。我們要求的是，他能知道高可用的知識後，去意識到高可用的重要性。
比如限流功能出現問題，他要能馬上認識到這是個很重要的問題，從而把解決的優先順序提到很高。
通過以上三個階段的學習和練習，基本是可以掌握這些技能的，這就夠了，剩下的細節，就靠在實際工作再實踐吧。
此也希望各位面試官，在招人的時候，如果遇到好苗子可以適當寬容一些，給新人們一點機會。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注我的公眾號。
