Nic Lin's Blog

喜歡在地上打滾的 Rails Developer

工程師應該知道的 C10K 問題

前陣子剛好在看一些跟 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 採用非阻塞方式,盡可能減少不必要的性能耗損。

參考來源

Share Comments
comments powered by Disqus