前陣子剛好在看一些跟 RDBMS 設計相關的討論，提到了 C10K 問題，覺得有點陌生就研究了一下。
Ruby 的作者在松本行弘在《代碼的未來》- 雲計算時代的編程一章中有更詳細的說明，有空可以看一下。
不必為還不夠格的規模做過度的設計
在做技術規劃或者架構設計時，應該要避免做「過度設計」，假上我們預期只有 1 萬的用戶量，那就不需要花精力花時間去考慮百萬用戶的狀況。就連淘寶這麼大，也是一步一步從 Apache、PHP、MySql 一路發展上去的，沒人能夠在一開始就預期淘寶會發展到今天這樣的規模，一旦規模發展起來，業務的增長會驅動技術的迅速發展，那麼在業務規模還不夠格的時候，說實在不需要對技術的未來擔心。
在商業邏輯上可能不會有太大的問題，因為需求總是不斷在變化，需要不斷應對。
但在底層所需的技術上，確實有可能發生「短視」的報應。
例如：
- 這個數據長度不會超過 16 位吧
- 這個程序不可能使用到西元 2000 年吧
結果就發生了千年蟲也有了 C10K 問題。
什麼是 C10K
C10K 就是 Client 10000 的問題，意思是說：「同時連接到 server 的 client 數量超過 10000 個的情況下，即使硬體性能足夠，卻依然無法正常提供服務」。
簡而言之，就是單機一萬個併發連接問題，最早的概念由 Dan Kegel 提出並發佈於個人網站（http://www.kegel.com/c10k.html）
連接的需求日益壯大
以前還沒有互聯網的時代時，同時能有 100 個在線用戶已經是不得了的事情，但現在因為業務驅動和技術發展的原因，除了普通的網頁瀏覽和表單提交， real time 的通信和互動交流越來越成為主流需求，keep-alive 技術也能讓瀏覽器產生長連接，實際在線的用戶只會越來越多，如果不能解決 C10K 問題，將導致需要不斷擴充服務器，而每一台服務器卻又不能做到物盡其用，即使設定了最好的 CPU 及 RAM。
在出現 C10K 以前的方向
系統設計的一個重要原則：KISS（Keep it simple and silly） 也有一種說法是：good design is simple and elegant
盡可能簡單易用，你的購買流程每用多一秒，便有額外 7％潛在客戶冷靜下來按 Alt-F4 放棄不買了，所以說在網站 C10K 之前，除了讓服務載入快速以外，也要讓整個流程夠簡單。
我覺得這部分也跟 FRUX & onboarding 有一定的關係。
解決 C10K 的方向
通過單個進程或線程服務於多個 client 需求，通過異步處理和事件觸發機制替換 polling，IO 採用非阻塞方式，盡可能減少不必要的性能耗損。