[[431094]]

在日常工作中，經常會遇到一些大促場景，需要評估系統的資源是否充足，是否需要增加資源，增加多少。

在系統設計面試中，有時也會遇到要求做一些估算類的題目：如果需要扛 100w QPS，需要多少機器……

想要做到“準確”的估算，需要對數字有一定的感覺。

第二章主要講的就是一些常用的數字。本文最后也會附加一些筆者平時積累的數字。

2 的次冪

2的次冪

英語里面常講 1 個 Million，1 個 Billion，分別是百萬、十億的意思。可以看到，以 3 個 0 為一組，層層遞進。

[[431095]]

千-百萬-十億

每個程序員都要了解的延遲數字

這里有一張表格反映了一些計算機的典型操作的耗時，配套的還有一個可視化網站，這個其實見得比較多了。

latency number tables

圖形化的網頁上可以選擇年份，數據也更準確。

latency number graph

• 從中可以得出一些明顯的結論：
• 內存比磁盤快。
• 避免 disk seek。

數據中心常常位于不同的區域，在它們之間傳送數據比較耗時。

從磁盤順序讀數據比從網絡順序讀數據慢。

可用性數字

工作中，我們常用幾個 9 來形容一個系統的可用性。100% 表示一個系統永遠不會掛，實際中的系統可用性指標大多處于 99% -100% 之間。

像一些云廠商，如 Amazon，Microsoft，Google 承諾的可用性是 3 個 9，即 99.9% 或以上，描述的是可用時間。

可用性

我的一些數字積累

• 某支付服務的支付峰值 60w QPS
• Go GC 打開寫屏障需要花費 10-30us
• 內網中，一次網絡請求的耗時是 ms 級別
• 萬兆網卡，1.25GB/s 打滿
• 4C8G 建 10w 到 20w 的連接沒有問題
• 因為機械硬盤的機械結構，隨機 I/O 與順序的 I/O 性能可能相差幾百倍。固態硬盤則只有十幾倍到幾十倍之間
• twitter 工程師認為，良好體驗的網站平均響應時間應該在 500ms 左右，理想的時間是 200-300ms
• 平均 QPS：日平均用戶請求除以 4w。日平均用戶請求，一般來自產品的評估。峰值 QPS：平均 QPS 的 2~4 倍

實戰

本章最后有一個實戰的例子：評估 twitter 的 QPS 和存儲容量。

先給出了一些預設：

• 300 個 million 的月活躍用戶
• 50% 的用戶每天都使用 twitter
• 用戶平均每天發表 2 條 tweets
• 10% 的 tweets 包含多媒體
• 多媒體數據保存 5 年

下面是估算的過程：

先預估 QPS：

• DAU(每天的活躍用戶數，Daily Active Users)為：300 million(總用戶數) * 50% = 150 million
• 發 tweets 的平均 QPS：150 million * 2 / 24 hour / 3600 second = ~3500
• 高峰期 QPS 一般認為是平均 QPS 的 2 倍：2 * 3500 = 7000 QPS

再來估算存儲容量：

假設多媒體的平均大小為 1MB，那么每天的存儲容量為：150 million * 2 * 10% * 1MB = 30 TB。5 年的存儲容量為 30 TB * 365 * 5 = 55 PB。

最后這兩個的估算過程是這樣的：

300 個 million * 10%* 1MB，1 MB 其實就是 6 個 0，相當于 million 要進化 2 次：million -> billion -> trillion，即從 M -> G -> T，于是結果等于 300 T * 10% = 30 T。

30 TB * 365 * 5 = 30 TB * 1825 = 30 TB * 10^3 * 1.825，TB 進化一次變成 PB，于是等于 30 * 1.825 PB = 55 PB。

一些建議

估算題的精髓在于過程，解決問題的過程比得到一個正確的結果更重要。

粗算。面試過程中，得到一個精確結果的意義不大，沒那么多時間且沒必要。例如 99987 / 9.1 可以簡化為 100,000 / 10。

寫下過程中所做的假設，方便之后參考。

寫下單位。例如 5MB，這會在后面的估算環節用到。

經常被問到的估算：QPS、峰值 QPS、存儲容量、服務器個數……

點評

估算能力還是挺重要的，日常工作中也用得到。例如新增一個 redis，評估一下需要多少臺機器資源……如果遇到這樣的場景，應該抓住機會鍛煉一下。

 

本章給出的 2 的次冪表格用處挺大，要收藏下來，用到的時候方便隨時查看。