前言
身體恢復後的第一個工作周，所有的時間幾乎被面試所佔滿。
一般每年的春節過後的三月與四月都是招聘旺季，那些對當下存在不滿的，或者想得到更好發展的小夥伴都開始蠢蠢欲動。
對面試官來說，這絕對不是一個快樂的季節，每當回憶起面試過程中的種種細節，我的內心總會掀起一陣陣的疲憊感。
面對堆得像小山一樣的簡歷，你必須用最短的時間，在其中找到有用的信息，並決定是否要邀約求職者進行進一步面談……這個流程，相信每位面試官都不陌生。而對求職者來說，要想給面試官留下深刻印象，並贏得面試機會，也必須學會在簡歷中的巧用一些關鍵詞彙。
在近二十年的職業生涯裡，我看過不下上千份的簡歷。在形形色色的關鍵詞中，打著 “有海量高併發經驗” 與 “精通技術原理” 這兩杆大旗的不在少數。
先說有經驗的，不是說自己對某某開源軟件的原理非常精通，或者對某項通訊協議有獨到的見解，就是說自己對高併發有比較深入的研究和豐富的開發實戰經驗，或者熟悉大併發技術。
再說沒經驗的，乾脆用懇求的口吻寫明，希望將來可以處理高併發業務與技術，開發數千萬/數億級別併發的應用。
看這架勢，似乎在絕大多數的程序員心中，只要擁有這兩項技能，職業生涯就能完美收官，從此走上人生巔峰。
但在這股痴迷之風的背後，當國內的許多程序員面向海量高併發場景時，是否真的有進行充分的思考？（文末有免費資料領取）
思考1：高併發場景背後的高成本
去年在某微信群中，和一些朋友爭論 “技術基礎化服務到底是選擇商業採購，還是開源自研？” 的話題。
有的人說，商業採購不僅貴，自主性差，而且體現不了技術價值。
有人則說，開源自研不僅投入成本高，技術風險大，而且費力不討好。
這種話題本來就是爹說爹有理，娘說娘有理的事，不同的企業或行業，不同的技術負責人都會得出不同的結論。
不過，有一個觀點大家都比較贊同，所謂技術方案，無論選擇哪一邊，都是基於最優成本的落地實踐。
這句話怎麼理解呢？
比如，一般在企業中做開發，都至少要有開發、集成測試、生產等多套環境，外加一些災備環境。如果用了服務器集群，那麼高併發方案的服務器的數量就要比堆硬件硬抗的方案翻好幾倍，而且運維的成本也會增加很多。
另外，為了能夠支撐這麼多的環境，同時降低眾多人肉運維的成本，自然需要招聘價格更昂貴的自動化運維工程師。
這一來一去，不管你的方案有多牛逼，在老闆眼裡似乎只看到了快速飆升的技術成本。而在許多程序員眼中，始終覺得只要方案好，成本不是問題，如果企業不願意承擔成本，那就是老闆摳門。
這些年裡，無論是我自己，還是身邊朋友，因為成本過高而夭折的項目不在少數，很多矛盾都由此而形成。
在我看來，如何用各種方式降低你方案的成本，並且說服企業應用，才是在實現高併發場景之前迫切需要思考的問題。
思考2：你擅長高併發？證明給我看
在部分高端技術崗位的面試中，我喜歡讓求職者在黑板上寫或畫出一些核心內容的實現過程。
原因很簡單，為了考察其簡歷中部分內容的真實性。
比如，簡歷上寫了 “有關高併發“ 的相關內容，我就一定會問上一句：最終解決的效果怎麼樣？
可惜的是，我感覺大多數的人都回答的不太理想。
有人說，你這是故意找茬吧。是嗎？那我來舉幾個例子看下。
比如，我會問在高併發場景中，你通常會用到負載均衡中的哪幾種分配方式？
或者問，當你採用了高併發策略後，與之前相比，對項目的改進和提升能達到多少？請用數據化的結果說明一下。
還會問，假設現有規模再擴大一倍，在現有的高併發策略上，你還會做出哪些調整？
在我的經歷中，絕大多數的人都會把Docker與虛擬化的理論跟我背誦一通，或者乾脆畫一張用2-3臺電腦實現的平均分配的負載均衡策略示意圖，只有少數幾位，能夠有條理的寫出負載均衡的原理與在各業務場景的落地實踐過程。
如果光看簡歷，可能你會覺得這些人都差不太多。
因此，在我看來，用原理和經驗深度的驗證方式，是發現是否擅長高併發場景的最佳套路。
什麼？你問那少數幾位最後都成功入職了嗎？很遺憾，大部分都因薪酬談不攏而告吹。
最後
不知道從什麼時候開始，但凡每次在面試中談到海量高併發的話題，我總會苦口婆心的嘮叨幾句。
比如說，痴迷高併發技術不是壞事，但良好的技術功底不僅僅體現在能處理高併發。
比如說，能解決實際業務問題的技能才是企業需要的，為要為了技術而技術。
比如說……
可能我真的年紀大了，感覺自己越來越嘮叨，看不慣的事務越來越多，啥事都要叨幾句。
這番話在對方聽來，也無非保持一個尷尬而不失禮貌的微笑，內心千萬只草泥馬奔騰而過，很想說幹你屁事。
對於我個人而言，過硬的技術是一定要有的，而解決實際業務問題的技能也是必不可少的，我也在我一位架構師朋友那要了一份學習資料來，資料包括Dubbo、Redis、Netty、zookee perSpring cloud、分佈式、高併發等架構技術，現在免費送給大家，也是希望能夠幫助到大家，關注私信我｛資料｝免費獲取
閱讀更多 JAVA架構進階 的文章
