2的次方表

次方                        对应值      常用值      字节数(Bytes)
---------------------------------------------------------------
7                             128
8                             256
10                           1024   1 thousand           1 KB
16                         65,536                       64 KB
20                      1,048,576   1 million            1 MB
30                  1,073,741,824   1 billion            1 GB
32                  4,294,967,296                        4 GB
40              1,099,511,627,776   1 trillion           1 TB

每个程序员都应该知道的延迟数

1 ns    |■ L1 Cache访问
5 ns    |■■ 分支预测失败
7 ns    |■■ L2 Cache访问
25 ns   |■■■ Mutex 操作
100 ns  |■■■■ 主内存访问
10us    |■■■■■■ Snappy 压缩 / 网络传输 1KB
150us   |■■■■■■■ SSD 随机读 4KB
250us   |■■■■■■■■ 内存读 1MB
500us   |■■■■■■■■■ 同数据中心 RTT
1ms     |■■■■■■■■■■ SSD 顺序读 1MB
10ms    |■■■■■■■■■■■■ 磁盘寻道
10ms    |■■■■■■■■■■■■ 网络传输 1MB
30ms    |■■■■■■■■■■■■■■ 磁盘顺序读 1MB
150ms   |■■■■■■■■■■■■■■■■■ 跨洲 RTT

从上面这些数字可以得出的关键洞见：

• 内存远快于磁盘，尽量减少寻道操作。
• 网络延迟高，跨机房通信尤其耗时。
• 压缩有助节省带宽，且成本相对廉价（快速）。
• 写入比读取贵约 40 倍、跨区域共享数据成本高。
• 若设计涉及高写共享的对象，锁竞争将严重影响性能。

🛠 案例：生成包含 30 个缩略图的搜索结果页

方案一：串行

• 对每张图像进行一次磁盘寻道 + 顺序读取。
• 延迟 ≈ 3010ms + (30256 KB) / (30 MB/s) ≈ 560 ms。

方案二：并行

• 并发发起 30 个读取请求（一次寻道 + 并行读取）。
• 延迟 ≈ 10 ms + (256 KB)/(30 MB/s) ≈ 18 ms（实际可能在 30–60 ms 范围）。

📌 结论：若延迟关键，则优先并行读取。

🧠 如何实操封底估算？

1. 掌握核心性能指标：如上列表。
2. 进行设计比较：例如，是否需要缓存、预生成缩略图、缓存策略等。
3. 识别未知因素：对不确定的变量，可做快速原型测试以量化延迟。
4. 不断测量子系统性能：获取真实指标，提升估算准确性。

---

✅ 总结建议

• 常做头脑中的封底计算，迅速筛选设计方向。
• 了解自己子系统的真实性能指标，不要光靠通用数据。
• 持续监控与测量系统，用现实反馈指导设计与预测。