給我第一感覺是這人可能培訓班出來的，因為培訓班天天拿這些來忽悠人，90%以上的的公司都沒什麼高併發，說這些無非顯得自己很牛逼，我對這種人都笑笑而已，同行之間都知根知底，忽悠外行吧！

高併發怎麼做？把別人寫好的框架，多配置幾個執行緒，內部程式碼基本還是單執行緒處理邏輯，最多做個互斥鎖，遇到高併發就選擇非併發的伺服器或者元件來避開，然後資料分發給多執行緒。

現在有多少人自己寫併發的？很少了

我是搬磚哥我來回答。

高併發的核心原理，是網路io的事件處理機制，就細節來說，一些重要環節，比如協議的斷包組包處理，還是比較複雜的，但就大部分的面試和日常工作來說，做到切實理解reactor機制的核心，就差不多了。關於高併發，可以多看下陳碩的那本書。

關鍵問題在於如果程式設計能力很稀鬆，那麼問題很大，簡單說交給一個任務，或者解決一個問題，動手能力弱的話，可能會久搞不定，還容易出錯。對於開發崗位來說，現在公司不論大小，日常工作不會有特大難度或規模的開發，換句話說誰的基本功更過硬，誰的任務往往完成的又快又好。

動手能力弱有個特別簡單直接的改進方法，就是刷leetcode之類，把程式碼先寫起來。不論什麼語言，先多寫，寫的多了自然不會稀鬆。

然後從簡單面向物件到最基礎的兩三個設計模式，序列到並行，結合自己的程式語言，把語言的特性逐漸吃透，過程也是和刷題一樣，寫程式碼不斷加深印象。包括學一門新的程式語言也是如此。

對大多數人來說，達到程式設計高手都不容易，但達到合格員工完全可以的，付出夠的努力即可，好腦子不如爛筆頭。

背的面試題唄。

現在招聘，尤其是網際網路公司招聘，一看學歷是否符合，二看面試題背的是不是6。

至於寫普通程式碼的能力，who cares ，反正進去是上螺絲。

滿嘴高併發的前提是真的要接觸過高併發系統，或者目前正在負責的就是高併發系統。

如果壓根就沒有接觸過高併發系統，或者連百萬級使用者的系統都沒負責過，就不要談高併發。因為，99%的程式設計師都接觸不到高併發系統。

高併發這個詞語對於我，或者說對於我的專案組一點不陌生，因為我們做的是真正的高併發系統，當然不是那麼的“高”，算是一般高併發吧！叢集的QPS在15萬左右。

高併發系統我們關注的問題非常多，例如：負載均衡、彈性擴容、限流、熔斷、降級、響應時間、快取等等問題。一個健壯的高併發系統限流和熔斷第一道防護線。因為海量的請求瞬間流入應用系統以後，如果系統處理不了，那就會擊垮後端的其它子系統以及其它元件，例如資料庫和快取。所以，必須做好系統的限流。當系統的QPS超過閾值，就要拒絕新來的請求，這樣保證子系統有足夠的時間去處理請求。

高併發系統面臨的另外一個問題就是“高”的傾斜性。根據“二八”原則，80%的請求都發生在20%的時間內。也就是說，系統只有在20%的時間面臨高併發請求，其餘時間並非高併發請求。而這種情況下，我們就要做好系統的彈性擴容伸縮。我們可以根據前置負載均衡器的QPS（SLB）、CPU等指標彈性的擴容或者收縮機器。這樣，當請求量大的時候，我們就自動擴容更多的機器來處理請求，當請求少的時候，我們就收縮機器，降低成本。

總之，高併發系統所涉及到技術是非常複雜的。如果想侃侃而談高併發概念，必須要親身實戰過高併發業務。透過高併發業務的實操，我們能更深的理解高併發的精髓。至於，編碼...我覺得是最底層的工作，只要思路清楚，寫程式碼就是個體力活。

幾個同事整天吹牛逼，連準備招聘的百度滴滴大牛都不放在眼裡，結果我請個假吧不停打電話問這問那，不會定位問題，不懂nginx配置、不懂閘道器作用……

一出問題不知道怎麼搞定，整天抓包啊、外掛啊、高併發啊一副裝B樣……

張嘴就來高併發，一開始是由培訓班帶來的風氣，他們這樣做主要是為了吸引生源，後來慢慢的就轉變成面試內容，90%的應用開發都沒有高併發

我很少會說高併發，但是我會經常說併發程式設計，兩個概念。高併發涉及到的知識點太多了，不光是併發程式設計這一塊。而且一般公司也用不到高併發。不過併發程式設計就不一樣了，併發程式設計還是很多專案會用到的。所以，切合實際，可以從併發程式設計入手。

跟我之前公司老闆他兒一樣！天天跑火車，牛逼哄哄，一會這技術一會那技術，結果做出來的東西跟屎一樣沒人用，哈哈

啥時代了，架構、元件滿天飛，

如果以前你沒做過編碼，

那麼以後也不要再說你編過碼，

你只不能是元件整合而已，

你不信？

最簡單的，

你有用C、java、c#或其它語言寫過base64演算法實現嗎？

千萬別再說你編過碼，

你只是弄點泥漿把混凝土塊兒進行粘砌而已，

你並不瞭解混凝土配比，

碎石、砂、水之間到底是什麼比例，

怎樣計算，怎樣測水，為什麼測水，

以及碎石到底要不要2-4的與1-3的級配，怎麼配比！

那麼編碼就別提了，好嗎？！

不會高併發。

自己寫了個框架，2000一年的入門伺服器。可能也就只能頂幾百併發吧。然後拿去做了個專案，後來法律出來了，停了不做了。

不過如果從技術角度看，要15萬的併發，快速的做法就是上硬體負載均衡。然後堆伺服器，資料直接進記憶體資料庫，後臺慢慢進關係資料庫。

畢竟我這邊就一個人，短時間要上大併發，還是用裝置頂省事。

題目就錯了，瀏覽了下解答也基本沒有對路的，說明網上沒有真章，只有眼球，哈哈。下面簡要說說，1、高併發除了頻寬還要看負載均衡，也就是說你演算法很糟糕但你分流很好，裝置到位，那麼程式設計師依需求折騰就是了，邏輯清晰不出錯即可，總體得看架構！2、目前負載均衡和堆疊方法很多，不是高鐵初期一夥沒有實踐經驗的程式設計“高手”如題主那樣，以為程式設計思想就能解決問題。3、如果是大資料處理能力，那麼考究的是資料結構和分佈處理方法，關鍵詞：資料結構、資料分佈、空間置換、負載均衡。得，就扯這些吧，估計也不會有懂的大牛會瀏覽。

都是國內的現狀鬧的，目前國內技術應用場景還是很侷限，基本上就是訂個飯，喊個車，下個單的所謂的2C場景。高併發確實是技術領域中難點之一，但是也只是很多難點的其中之一。而國內市場現在似乎把高併發當作衡量一個技術人員水平高低的主要標準，甚至是唯一標準，這也就造成了市場上的程式設計師言必稱高併發，沒有做過高併發或者不需要做高併發的程式設計師也去專研高併發，所以圈子裡面關於高併發的帖子，影片，培訓資料也層出不窮……

好多網友都回應說碰不到高併發系統，今年一共做了4個系統，這4個系統都碰到併發的問題，達不到萬級的QPS，但是有好幾千還是有的，說到這裡估計很多同學可能會說這種系統沒有挑戰性之類的了，請認真往下看，我們這幾個系統有一個很大的特點，業務的併發主要集中在訂單系統，日訂單寫入300萬條以上，因為業務特殊性，訂單業務每條當天必須更新操作兩次才能完成業務，算下來寫操作是900萬次以上每天，同時訂單表有兩個欄位是展示業務內容的，這兩個欄位長度都是8K才能存放下業務內容，每個使用者都能在前端時間倒序分頁查詢，最要命的來了，系統產生這些訂單的時候90%集中在下午某個時間段一個小時以內，意味著一個小時之內要完成的業務量很大，挑戰來了，我在解決這個併發問題花了以下幾個步驟：

1、伺服器必須使用高效能SSD硬碟

3、由於時間與運維成本問題，快取部分沒有用redis，直接記憶體快取近3天訂單熱資料，記憶體中的資料根據使用者查詢的方式寫了個簡單的記憶體索引資料結構，資料結構大概這樣，首先是資料hashmap存放，userid做key，value放一個user order list時間倒序集合，快取同步策略在資料庫中加一個int64 dataversion欄位做快取同步版本號，這個dataversion我用的是snowflake演算法生成的自增int64，5s記憶體與資料庫同步一次，架構非常簡單。

核心業務就上面這些，兩個web服務nginx負載均衡，8c/16T E5單臺伺服器帶動峰值8K QPS偶爾一個超過3s的session，主要的效能瓶頸是在訂單快取服務上，之前自己寫的單執行緒RPC框架在抗大量的分頁請求的時候確實拖了下後退，不過不算太糟糕，web服務做了一個請求頻率限制，nginx負載均衡策略用的是IP session，這個架構基本上夠用，好多人做高併發系統非常糾結於那些0複製、xxx io、分散式事務、xxx框架xxx特性亂七八糟的，忽略了程式本身，高併發並不是什麼多大事，出事的地方是你的併發到底有多大，像我這個系統級別的國內有幾個專案能達到，月訂單量接近億級別，億級別資料庫表，當然做tx，ali這種級別的系統挑戰就來了，99.999%國內的系統我這個解決方案都能解決，並且低開發成本。

編碼能力是最難衡量的。

靠簡歷？扯。

靠講演算法？演算法和實際程式設計不是一回事。當然能講清楚，經得住拷問，說明他資質還可以。

靠解釋框架原理、編譯原理？好吧，汽車開的好和了解汽車怎麼造出來的是不同層面，只能說有一定幫助。

哪還有什麼方法？我主要觀察對方的邏輯能力。比如講問題時的思考方式，尤其讓他講他寫過的最複雜或最有意思的程式的內部邏輯。有時，我也會準備好電腦，現場讓他給我寫一段，或者看一段程式碼再給我講解。更準確的評價，還是要靠入職一段時間後的表現。

以上這些前提是，評價者或面試者是優質程式設計師出身。總之，一個好程式設計師抵至少三個垃圾程式設計師，甚至不如不要那三個垃圾程式設計師。

一般公司併發能有一百就很不錯了，上千已經是業內有名了，上萬已經是領頭羊了。但是工業軟體另說，採集器一秒一個數據，上萬採集器一秒就一萬的資料。滿嘴高併發的程式設計師大部分都沒有高併發經驗，因為高併發更多的面對波峰請求，容錯處理，容災處理，帶損服務，大資料處理，防禦機制做得多，純粹的高併發離開業務都是不靠譜的，比如直播類的併發和12306搶票處理就不一樣，電商的雙十一和大型圖片儲存中心的併發處理又不一樣，遊戲的高併發又不一樣。編碼能力不行又滿嘴高併發這必須是個玩虛高手，搞關係他很行，甩鍋也是一般好手。我有幸參與過秒請求超過5萬的專案，說實話，很痛苦，光是擴容和修改資料庫都讓我熬了好多個通宵。後來實在是太痛苦了，把cpp換成可以熱更新的語言，全部重寫了一遍。即使我已經是bug率很低了，一天造一個，久了也受不了。熱更要停機，秒請求5w，更新停一次機我就要熬到凌晨四點多，這個時候請求量還上五千。做高併發的人，基本上都比較沉默寡言，因為被罵太多了，只能默默承受。

現在不說高併發，大資料，微服務就好像自己是畢業生一樣。不過講道理，除了極個別的人外，大多數做的就是全行業都瞧不起的curd，大多數做的就是應用級的開發。搞清業務，搞清資料流向，模組關係，有擔當，我覺得這就是一個合格的開發人員，甚至是高階開發人員。而且在基於百度程式設計的情況下，只要不是特別變態的併發，大多數網上的主流方案都能勝任。推負載，多級快取，佇列削峰，非同步處理，用用這些基本足夠。

面過一個只有幾百個使用者的系統的開發者，聲稱處理過千萬級的併發。

我問了下select和epoll模型，不懂。

然後我又問了下zero copy，不懂。

然後…

就沒有然後了。

面試造火箭，入職擰螺絲

上週末，和阿里的一個朋友聊天。他是5年前去的阿里巴巴，我們都對“面試造火箭，入職擰螺絲”深有感觸，然後就這個話題扯了一頓飯的時間。

這句話實際上是有點諷刺和調侃的味道，描述的意思是說：面試的時候都是滿嘴跑火車，各種高併發，分散式，高效能，各種AI技能，機器學習技能。入職以後才發現自己做的無非就是CRUD，就像工地上擰螺絲的工人一樣。

找過工作，進入大廠的小夥伴都有這樣一個共識：重視基礎的大廠（如位元組），會在計算機網路、演算法、作業系統上問到你懷疑人生。重視實戰的大廠（如阿里），會在高併發、資料庫效能調優等領域問到你招架不住。

我覺得最主要的原因是：狼多肉少，競爭太激烈了。

這幾年網際網路行業的碼農工資確實高，導致很多學習機械工程的、資訊工程的、物理、數學，甚至一些學習文科專業的人轉行學習程式設計。這樣就帶來了一個很大的問題：加速程式設計師這個行業的內卷。

最近這兩年，“內卷”、“35歲”、“青春飯”這些詞在程式設計師領域廣泛擴散，很多人都很急躁、焦慮。因此，有些人就學會了刷面試題，鍛鍊口才，很少有人會沉下心來專研技術和業務。

從面試官的角度來看，想招到一個有造火箭能力的程式設計師，毫無違和感。但是，面試官本身也有問題，你們公司能造火箭嗎，淨問一下高階不可觸碰的問題。

面試官想從面試中看到程式設計師的上限，這沒有問題；問題是很多面試官假借面試之便，行刁難人之實。結果真正能做事不會表達的候選人沒有進入公司，反而是那些滿嘴跑火車，大談特談高併發的選手進入了公司。

進入公司以後，發現自己招來的員工，編碼能力稀鬆平常。悔之晚矣，要知道辭退一個員工是何其難也。

針對不同的崗位，面試官要有不同的面試策略，不是所有的崗位都要求懂高併發、資料庫調優。只有這樣，才能讓候選人慢慢的不再刷leetcode，公司才能招到合適的人才。

高併發是基礎吧，需要特別說我高併發咋厲害嗎，主要還是看場景解決問題。比如每秒40tps，10萬資料讓你10分鐘搞定，你可能就得考慮併發處理，但是100萬，1000萬那麼就不僅僅是併發處理了