如果不想閱讀本文，喜歡看視訊可以到這裡www.bilibili.com/video/BV1KQ4y1i7k... 【本文強烈結合視訊看，否則你的理解可能產生很大的偏差】
本文閱讀必備條件
1 CURD 3年以上
2 已經實戰過HTTP協議和網路程式設計
3 結合視訊理解本文簡短的陳述
4 本文的內容只對技術上進行陳述，並不針對任何朋友。
你怎麼解決高併發的？
1 百度一下，抄一下答案就可以解決高併發
2 CSDN 抄一下就可以解決高併發
3 請教你所認為的頂尖大佬就可以解決高併發
4 請教頭銜比較響的大佬就可以解決高併發
5 其它手段
本文內容圍繞高併發解決可行方案探討
在我沒有正式說之前，相信一部分大佬已經有了自己的具體可行方案，甚至已經在大公司已經實戰過，並且已經在大公司取得非凡的成就，同時經驗豐富，已經實施過在市場只要一出說某APP名就可以響震大江南北的公司。那麼本文你就不需要看了。不然會浪費你大佬寶貴的時間。
我們要說的是可行方案，並不是理論，也不是看不見模不著的東西，相信沒有人會會喜歡玄學。所以本文不會偏向理論進行陳述。而是偏向實戰派。
先說答案，高併發解決方案就2個條件
1 技術上能支援到位（整個技術團隊）
2 錢能支援到位
如果說你的老闆只給1Mbits的寬頻和1G的CPU和1G的記憶體，這樣的配置，我相信你技術縱然領先歐美程式設計師，你也無法解決高併發的問題。很顯然當你上來就要堆機器，提寬頻，提配置，搭叢集，弄分散式，顯然得老闆出錢到位！可見解決高併發並不是我們技術人員的事情，畢竟沒有錢你堆不出來機器！
那麼關於堆機器，怎麼堆，分散式和叢集，微服務怎麼弄，這方面的東西我在相關視訊裡已經講過，在這裡不在陳述，我下面要說的是可行的技術方案。因為關於堆機器，提寬頻速度，提配置是老闆的事情，老闆只要給錢到位，剩下的事情就是技術上的支援。
什麼是高併發
PS:LINUX 下一切皆檔案
我的定義：單位時間內在伺服器端程式裡fd目錄建立了大量的socket檔案
解釋：如果你看過我講的網路程式設計，必然知道socket,bind,accept函式（我這裡只講Linux，因為我開發的專案幾乎執行在LINUX上）【也許你是php,golang ,java ,nodejs,c++,rust，python程式設計師，但我想告訴你的是，這些程式語言在低層執行時呼叫的就是socket,bind,listen,accept，如果你不相信，可以立馬找我，我跟你講,保證你信】當程式呼叫socket時，產生一個檔案fd,當程式接收客戶端連線時accept產生一個檔案。它們產生的檔案會放在程式的fd目錄下存放【顯然你要了解一下程式執行時，它的相關資料到底在哪裡，特別是網路檔案在哪裡,有哪些資料】
任何程式語言編寫的網路程式都要接收客戶端連線【沒有誰不敢這樣做】，它們在低層用的就是accept【我不管你什麼語言，顯然你可能不相信我的話，此時找我麻煩，我可以跟你說】，當它接收客戶端時間，會生成一檔案放在程式的指定目錄下，並有相應的收發緩衝區，定時器等資料由系統維護。
我假如你公司的架構就是這樣的
這裡只是隨便一個架構，其實現實中各種架構，我說一個希望你能舉一反三
在公司裡開發專案，HTTP協議的使用可以說是佔比最高的協議了，許多API介面HTTP協議是佔比非常高的。
注意：我希望你最好親自實現過HTTP協議。否則你可能不知道我在講什麼
這圖有100個萬個客戶端同時發起請求，那麼就是100萬個併發，在程式裡會呼叫accept100萬次，也會生成100個檔案【檔案的fd值可能會複用，但它確實是100萬個檔案】
- 100萬個連線會產生100萬個檔案【總之要生成這麼多檔案】
- 100萬個連線【假如每次響應的報文如圖所示為100KBbytes，則是100萬*100Kb的資料量】
- 業務層的檔案【假如一次請求要開啟100個檔案從入口檔案到達控制器為檔案為100個的話，且每個檔案的程式碼量為1Kb】則會openat100個檔案100萬+會100個檔案1Kb*100萬次的記憶體申請，因為PHP直譯器在解析檔案時會先開啟檔案，再讀取檔案內容，再進行詞法解析，語法解析，語法優化，最終目的碼生成opcode【這東西我講過，不在重複，如果你不曉得自己看看或是百度一下】
上面的資料一些大佬是沒有感覺的，我相信下面的方法你會有感覺！！！
- 你立馬辭職去工地打工，工作就是扛水泥，一天併發量就是100萬包
- 每包水泥多少重量，你自己算吧
上面的事情只要你連續做一個月，我相信你會有感覺，感覺就是累死了，要麼爽死了，那你的解決方案就是
1 讓老闆加人【加人意味著要加錢】
2 水泥重量減輕
3 併發次數減少
只要上面做到了那你就會輕鬆許多【上面的方案 涉及到加錢和減輕水泥重複】你才能輕鬆的應付你的業務扛水泥。
上面你的解決方案就是：加人【加錢，不給錢誰幫你幹】，減輕水泥重量，減少併發次數
- 回到我們上面的LNMP架構上【雖然沒有加資料庫】
那麼方案就是：
1 在技術上減少業務層的程式碼量及檔案資料【只針對指令碼語言如php,python】 【我希望你能看一下視訊，否則你也不知道為啥這樣】 【相當於你扛水泥的距離減短到20米】
2 減少HTTP報文的大小 【相當你扛水泥的重量減輕為10斤】
3 堆機器分攤100萬流量【顯然加錢】 【相當於工地加人扛水泥】
技術上我們干涉的：資料包傳輸大小，業務層程式碼質量技術上我們干涉的：資料包傳輸大小，業務層程式碼質量，架構
最終的解決方案出來【技術上能干涉的地方】【該方案的結果希望你結合視訊看】
1 業務層程式碼精簡，業務層程式碼儘量分攤到前端做，比如簡單的時間格式處理，欄位拼裝，圖片輸出，檔案匯出等簡單的業務，這樣可以減輕伺服器的運算壓力【顯然前端的大佬不會高興，因為嚴重影響他模大魚】 ===》顯然一個專案你得前端的大佬配合你，否則你的專案全是你伺服器承擔運算壓力。會嚴重加重CPU和記憶體的資源消耗。畢竟客戶機都是高配置的CPU和記憶體手機了，以及高配置的電腦了。
2 資料傳輸儘量減少不必要的欄位，欄位設計簡短及見名知義即可，報文少加沒有意義的頭資訊。
3 換架構，換框架【顯然PHP-FPM派不會高興，因為會增加某些人的難度】
因為一個高效能的API或是高效能的專案必然是滿足如下條件
1 佔用CPU和記憶體資源最少 【少造大量的檔案和過度的程式碼層封裝】
2 佔用寬頻傳輸資源最少 【少造大量的HTTP報文，顯然你沒有寫過HTTP協議可能不是特別理解】
3 傳輸時間最快 【只有傳輸報文足夠小，才能快===》還沒說有提寬頻配置】
總結
如果上面的內容你不滿意【你已經看了視訊】【你已經實戰】可以找我麻煩。
我幫你解決你所謂的高併發【前提是你們公司你能做主，你說的話老闆能聽】
本作品採用《CC 協議》，轉載必須註明作者和本文連結