高併發是互聯網分佈式系統架構的性能指標之一,它通常是指單位時間內系統能夠同時處理的請求數,
簡單點說，就是QPS(Queries per second)。
那麼我們在談論高併發的時候，究竟在談些什麼東西呢？
高併發究竟是什麼?
這裏先給出結論:
高併發的基本表現爲單位時間內系統能夠同時處理的請求數,
高併發的核心是對CPU資源的有效壓榨。
舉個例子，如果我們開發了一個叫做MD5窮舉的應用，每個請求都會攜帶一個md5加密字符串，最終系統窮舉出所有的結果，並返回原始字符串。這個時候我們的應用場景或者說應用業務是屬於CPU密集型而不是IO密集型。這個時候CPU一直在做有效計算，甚至可以把CPU利用率跑滿，這時我們談論高併發並沒有任何意義。(當然，我們可以通過加機器也就是加CPU來提高併發能力,這個是一個正常猿都知道廢話方案，談論加機器沒有什麼意義，沒有任何高併發是加機器解決不了，如果有,那說明你加的機器還不夠多!🐶)
對於大多數互聯網應用來說,CPU不是也不應該是系統的瓶頸，系統的大部分時間的狀況都是CPU在等I/O (硬盤/內存/網絡) 的讀/寫操作完成。
這個時候就可能有人會說，我看系統監控的時候，內存和網絡都很正常，但是CPU利用率卻跑滿了這是爲什麼？
這是一個好問題,後文我會給出實際的例子，再次強調上文說的 ‘有效壓榨’ 這4個字,這4個字會圍繞本文的全部內容！
控制變量法
萬事萬物都是互相聯繫的，當我們在談論高併發的時候，系統的每個環節應該都是需要與之相匹配的。我們先來回顧一下一個經典C/S的HTTP請求流程。
如圖中的序號所示:
1 我們會經過DNS服務器的解析，請求到達負載均衡集羣
2 負載均衡服務器會根據配置的規則，想請求分攤到服務層。服務層也是我們的業務核心層，這裏可能也會有一些PRC、MQ的一些調用等等
3 再經過緩存層
4 最後持久化數據
5 返回數據給客戶端
要達到高併發，我們需要 負載均衡、服務層、緩存層、持久層 都是高可用、高性能的，甚至在第5步，我們也可以通過 壓縮靜態文件、HTTP2推送靜態文件、CDN來做優化，這裏的每一層我們都可以寫幾本書來談優化。
本文主要討論服務層這一塊，即圖紅線圈出來的那部分。不再考慮講述數據庫、緩存相關的影響。
高中的知識告訴我們，這個叫 控制變量法。
再談併發
網絡編程模型的演變歷史
併發問題一直是服務端編程中的重點和難點問題，爲了優系統的併發量，從最初的Fork進程開始，到進程池/線程池,再到epoll事件驅動(Nginx、node.js反人類回調),再到協程。
從上中可以很明顯的看出，整個演變的過程，就是對CPU有效性能壓榨的過程。
什麼?不明顯?
那我們再談談上下文切換
在談論上下文切換之前，我們再明確兩個名詞的概念。
並行：兩個事件同一時刻完成。
併發：兩個事件在同一時間段內交替發生,從宏觀上看，兩個事件都發生了。
線程是操作系統調度的最小單位，進程是資源分配的最小單位。由於CPU是串行的,因此對於單核CPU來說,同一時刻一定是隻有一個線程在佔用CPU資源的。因此，Linux作爲一個多任務(進程)系統，會頻繁的發生進程/線程切換。
在每個任務運行前，CPU都需要知道從哪裏加載，從哪裏運行，這些信息保存在CPU寄存器和操作系統的程序計數器裏面，這兩樣東西就叫做 CPU上下文。
進程是由內核來管理和調度的，進程的切換隻能發生在內核態，因此 虛擬內存、棧、全局變量等用戶空間的資源，以及內核堆棧、寄存器等內核空間的狀態,就叫做 進程上下文。
前面說過,線程是操作系統調度的最小單位。同時線程會共享父進程的虛擬內存和全局變量等資源，因此 父進程的資源加上線上自己的私有數據就叫做線程的上下文。
對於線程的上下文切換來說，如果是同一進程的線程，因爲有資源共享，所以會比多進程間的切換消耗更少的資源。
現在就更容易解釋了，進程和線程的切換，會產生CPU上下文切換和進程/線程上下文的切換。而這些上下文切換,都是會消耗額外的CPU的資源的。
進一步談談協程的上下文切換
那麼協程就不需要上下文切換了嗎？需要，但是不會產生 CPU上下文切換和進程/線程上下文的切換,因爲這些切換都是在同一個線程中，即用戶態中的切換，你甚至可以簡單的理解爲，協程上下文之間的切換，就是移動了一下你程序裏面的指針，CPU資源依舊屬於當前線程。
需要深刻理解的，可以再深入看看Go的GMP模型。
最終的效果就是協程進一步壓榨了CPU的有效利用率。