前些天，朋友圈被一首歌刷屏了。
數據有多牛逼？除了攬獲各大新聞頭條，新歌發售3小時，數字專輯就在QQ音樂賣了360萬張。以單價3元計算，一首《說好不哭》已狂攬千萬，無人匹敵。
結果因為訪問量太大，不少網友反映“QQ音樂崩了。。。”
在大家眼裡，好像只有微博服務器是“不堪一擊”的。那天晚上，QQ音樂持續崩潰，周杰倫以一己之力成為了幹翻QQ音樂服務器的男人。
在這首新歌裡，大家還意外看到“週五合體”。還原了經典場景，也掀起了一波關於青春的回憶殺。當回憶和回憶相撞，啪，淚花四濺。
歌迷有沒有被感動哭我不知道，但是QQ音樂的程序員估計是要哭了。不奮戰個一天一夜，怎麼對得起嗷嗷待哺的歌迷朋友們。
諸如雙十一淘寶癱瘓，明星戀情導致微博宕機事件，說到底還是“高併發”的問題。
高併發帶來的後果
服務端：
導致站點服務器/DB服務器資源被佔滿崩潰，數據的存儲和更新結果和理想的設計是不一樣的，比如：出現重複的數據記錄，多次添加了用戶積分等。
用戶角度：
尼瑪，這麼卡，老子來參加活動的，刷新了還是這樣，垃圾網站，再也不來了！
程序員的經歷： 在做公司產品網站的過程中，經常會有多樣需求，如果沒有考慮到高併發下的數據處理，就會出現各種超出正常邏輯的現象，因為這些都是面向大量用戶的，而不是像做ERP管理系統只是面向員工。
迴歸技術本身，面對如此大的高併發流量和屢次崩潰的系統，程序員們如何抵擋？
提高系統併發能力方式
在這個“雲”的時代，提高分佈式系統併發能力的方式，方法論上主要有兩種：垂直擴展（Scale Up）與水平擴展（Scale Out）。
1、垂直擴展提升單機處理能力。垂直擴展的方式又有兩種：
增強單機硬件性能，例如增加 CPU 核數如 32 核，升級更好的網卡如萬兆，升級更好的硬盤如 SSD，擴充硬盤容量如 2T，擴充系統內存如 128G；
提升單機架構性能，例如使用 Cache 來減少 I/O 次數，使用異步來增加單服務吞吐量，使用無鎖數據結構來減少響應時間。
2、水平擴展
只要增加服務器數量，就能線性擴充系統性能。虛擬化技術的出現，讓水平擴展變得輕鬆且簡單。現在的雲主機幾乎是虛擬主機，而不是物理主機。這樣的話，線性擴充也就是分分鐘的事，前提是要有足夠的物理主機支撐。
高併發的三個經典問題
1、單臺服務器最大併發
單臺服務器最大併發問題，一般是指一臺服務器能夠支持多少 TCP 併發連接。一種理論說法是受到端口號範圍限制。操作系統上端口號 1024 以下是系統保留的，從 1024-65535 是用戶使用的。由於每個 TCP 連接都要佔一個端口號，所以我們最多可以有 60000 多個併發連接。但實際上單機併發連接數肯定要受硬件資源（內存、網卡）、網絡資源（帶寬）的限制。特別是網卡處理數據的能力，它是最大併發的瓶頸。
2、C10K 併發連接問題
C10K 併發連接問題是指單機 1 萬個併發連接問題。如何突破單機性能侷限，是高性能網絡編程所必須要直面的問題。這些侷限和問題最早被 Dan Kegel 進行了歸納和總結，並首次成系統地分析和提出解決方案，後來這種普遍的網絡現象和技術侷限都被大家稱為 C10K 問題。C10K問題本質上是操作系統的問題。對於 Web1.0/2.0 時代的操作系統而言， 傳統的同步阻塞 I/O 模型都是一樣的，處理的方式都是 requests per second，併發 10K 和 100K 的區別關鍵在於 CPU。創建的進程線程多了，數據拷貝頻繁（緩存 I/O、內核將數據拷貝到用戶進程空間、阻塞）， 進程/線程上下文切換消耗大，導致操作系統崩潰，這就是C10K 問題的本質。
3、C10M 併發連接問題
C10M 併發連接問題指的是單機服務器實現 C10M（即單機千萬併發連接）。回顧過去的 10 年裡，我們面臨高性能網絡編程領域著名的 C10K 問題，最終也成功提出解決方案。下一個 10 年，是時候考慮 C10M 併發問題了。
在很多程序員眼中，掌握海量高併發技能，就能走上人生巔峰。
anyway，學得會就學。我倒覺得與其痴迷某些技術的尖端，不如解決某些行業的業務落地。
經典評論
1、操作系統上端口號1024以下是系統保留的，從1024-65535是用戶使用的。由於每個TCP連接都要佔一個端口號，所以我們最多可以有60000多個併發連接。我想有這種錯誤思路的朋友不在少數吧？（其中我過去就一直這麼認為） 我們來分析一下吧。 如何標識一個TCP連接： 系統用一個4四元組來唯一標識一個TCP連接：{local ip, local port,remote ip,remote port}。好吧，我們拿出《UNIX網絡編程：卷一》第四章中對accept的講解來看看概念性的東西，第二個參數cliaddr代表了客戶端的ip地址和端口號。而我們作為服務端實際只使用了bind時這一個端口，說明端口號65535並不是併發量的限制。 server最大tcp連接數： server通常固定在某個本地端口上監聽，等待client的連接請求。不考慮地址重用（unix的SO_REUSEADDR選項）的情況下，即使server端有多個ip，本地監聽端口也是獨佔的，因此server端tcp連接4元組中只有remote ip（也就是client ip）和remote port（客戶端port）是可變的，因此最大tcp連接為客戶端ip數×客戶端port數，對IPV4，不考慮ip地址分類等因素，最大tcp連接數約為2的32次方（ip數）×2的16次方（port數），也就是server端單機最大tcp連接數約為2的48次方。
這個也算不上大牛吧，會數學的基本上都算得出。不考慮端口被佔用，ip地址分配的問題，理論上一臺機器能夠監聽六萬多個端口，同時每個端口可以被全世界所有的ipv4地址訪問，合計就是 最大端口號乘以最大ip數，結果就是你電腦炸了。
操作系統上端口號1024以下是系統保留的，從1024-65535是用戶使用的。由於每個TCP連接都要佔一個端口號，所以我們最多可以有60000多個併發連接。我也覺得這個說法有問題，併發數指向的應該是佔用一個端口號的服務的問題。
一個socket，更準確的應該說是一個socket對，指的是ip:port（發起方，客戶端）ip:port（監聽方，服務端），這是一個socket對，服務端可以固定監聽一個serverSocket，這是端口監聽的概念，可以監聽65535個端口。當服務端監聽80端口，那麼客戶端可以發起60000多對socket，加上ip變化，所以理論上服務端統一個端口可以接受到2^32（ip容量，ipv6不考慮）*65535個socket對。
2、這種適合最忙的不一定是敲代碼的，應該是運維吧？運維是運維，程序員是程序員，不要混為一談。
程序員會的運維基本都要會，程序員不會的運維也要會。
3、我在想，當服務器爆滿的時候做個排隊不行嘛，LOL週年慶經常排隊。
不錯的想法。
戰鬥之夜排隊到100000
音樂軟件啊，畢竟不是遊戲，我打開這個窗口可能就是現在有時間想聽幾首歌，但是來個排隊，肯定不妥噻。
Lol一開始也是沒排隊的，後面才加的。可能QQ音樂還沒遇到需要排隊的情況，畢竟一直都比較穩定。
4、為什麼單機最大連接數和端口數量有關啊，一個服務不是開啟一個端口嘛？
你說出了我的疑惑。
有關的，因為受限制服務器的端口。
5、樓主說的很對啊，要想工資多，就得有高併發問題的解決辦法。
6、 我覺得也是尖端雖然重要，但是現實還是業務。
7、誰能看到幕後程序員的辛苦？只有同行們惺惺相惜吧。
8、話說服務器不都是多線程的嗎，共用一個端口，何來端口數目限制一說呢？
9、林俊杰的 將故事寫成我們，qq音樂也是炸了。
10、可能他們需要多臺服務器去負載，畢竟每臺機器端口號有限制。
閱讀更多 小陸老師 的文章
