# c10k編程 比較傳統的服務端程序（PHP、FAST CGI等），大多都是通過每產生一個請求，都會有一個進程與之相對應，請求處理完畢后相關進程自動釋放。由于進程創建、銷毀對資源占用比較高，所以很多語言都通過常駐進程、線程等方式降低資源開銷。即使是資源占用最小的線程，當并發數量超過1k的時候，操作系統的處理能力就開始出現明顯下降，因為有太多的CPU時間都消耗在系統上下文切換。 由此催生了c10k編程，指的是服務器同時支持成千上萬個連接，也就是concurrent 10 000 connection（這也是c10k這個名字的由來）。由于硬件成本的大幅度降低和硬件技術的進步，加上一臺服務器同時能夠服務更多的客戶端，就意味著服務每一個客戶端的成本大幅度降低，從這個角度來看，c10k問題顯得非常有意義。 理想情況下，具備c10k能力的服務端處理能力是c1k的十倍，返回來說我們可以減少90%的服務器資源，多么誘人的結果。 c10k解決了這幾個主要問題： - 單個進程或線程可以服務于多個客戶端請求 - 事件觸發替代業務輪詢 - IO采用非阻塞方式，減少額外不必要性能損耗 c10k編程的世界，一定是異步編程的世界，他倆絕對是一對兒好基友。服務端一直都不缺乏新秀，各種語言、框架層出不窮。筆者了解的就有OpenResty，Golang，Node.js，Rust，Python(gevent)等。每個語言或解決方案，都有自己完全不同的定位和表現，甚至設計哲學。但是他們從系統底層API應用、基本結構，都是相差不大。這些語言自身的實現機理、運行方式可能差別很大，但只要沒有嚴重的代碼錯誤，他們的性能指標都應該是在同一個級別的。 如果你用了這些解決方案，發現自己的性能非常低，就要好好看看自己是不是姿勢有問題。 > c1k --> c10k --> c100k --> ??? 人類前進的步伐，沒有盡頭的，總是在不停的往前跑。c10k的問題，早就被解決，而且方法還不止一個。目前方案優化手段給力，做到c100k也是可以達到的。后面還有世界么？我們還能走么？ 告訴你肯定是有的，那就是c10m。推薦大家了解一下[dpdk](http://www.dpdk.eu)這個項目，并搜索一些相關領域的知識。要做到c10m，可以說系統網絡內核、內存管理，都成為瓶頸了。所以要揭竿起義，統統推到重來。直接操作網卡繞過內核對網絡的封裝，直接使用用戶態內存，再次繞過系統內核。 c10m這個動作比較大，而且還需要特定的硬件型號支持（主要是網卡，網絡處理嘛），所以目前這個項目進展還比較緩慢。不過對于有追求的人，可能就要兩眼放光了。 前些日子dpdk組織國內CDN廠商開了一個小會，阿里的朋友說已經用這個開發出了c10m級別的產品。小伙伴們，你們怎么看？心動了，行動不？