搞定系统设计 02：估算的一些方法
在日常工作中，經常會遇到一些大促場景，需要評估系統的資源是否充足，是否需要增加資源，增加多少。
在系統設計面試中，有時也會遇到要求做一些估算類的題目：如果需要扛 100w QPS，需要多少機器……
想要做到“準確”的估算，需要對數字有一定的感覺。
第二章主要講的就是一些常用的數字。本文最后也會附加一些筆者平時積累的數字。
2 的次冪
2的次冪英語里面常講 1 個 Million，1 個 Billion，分別是百萬、十億的意思。可以看到，以 3 個 0 為一組，層層遞進。
千-百萬-十億每個程序員都要了解的延遲數字
這里有一張表格反映了一些計算機的典型操作的耗時，配套的還有一個可視化網站，這個其實見得比較多了。
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 的次冪表格用處挺大，要收藏下來，用到的時候方便隨時查看。
總結
以上是生活随笔為你收集整理的搞定系统设计 02：估算的一些方法的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 曹大：我的快速阅读法
- 下一篇： 简单看看 Go 1.17 的新版调用规约