2025：现代硬件限制，系统设计考虑
这段文字强调了在技术快速迭代的行业中，持续学习现代硬件限制对系统设计的重要性。以下是根据你的提纲整理的内容：
Modern Hardware Limits（2025年硬件基准）
- CPU：单核性能趋于瓶颈，但多核（128+ vCPU）和异构计算（GPU/TPU）普及，单实例可处理百万级QPS。
- 内存：云实例普遍支持1-12TB RAM，内存数据库（如Redis）可承载TB级热点数据。
- 存储：
- SSD：单盘100TB+，百万IOPS，延迟<100μs。
- 对象存储（如S3）：EB级扩展，成本<$0.01/GB/月。
- 网络：云内网100Gbps+，跨AZ延迟<1ms，全球CDN延迟<50ms。
Applying These Numbers in System Design Interviews
- 拒绝过时数据：2020年教科书可能说“单机内存上限几百GB”，但2025年单实例可存TB级数据，无需过早分片。
- 动态调整设计：例如，2025年Redis集群可缓存PB级数据（通过SSD+内存混合存储），无需直接引入复杂CDN。
Caching
- 现代缓存容量：
- Redis 7.0：单分片1TB+内存，横向扩展至PB级。
- CDN缓存：Edge节点可存动态内容（如用户个性化数据），延迟<10ms。
- 面试技巧：被问到“如何缓存10亿条热点数据？”时，回答：“单Redis集群即可承载，无需分片”（2025年硬件支持）。
Databases
- 单机性能：
- PostgreSQL 16：单机可处理百万级TPS（via NVMe SSD+优化索引）。
- MySQL 8.0：1TB内存缓冲池成为标配，90%查询无需磁盘IO。
- 分片阈值：2025年建议：
- 单表>100TB或写入>500万TPS时再考虑分片（过去可能是1TB/10万TPS）。
Application Servers
- 容器密度：单Kubernetes节点可运行千级Pod（via轻量级运行时如gVisor）。
- 无状态扩展：单EC2实例（m7g.16xlarge）可处理50万并发WebSocket连接（via io_uring+EPOLL）。
Message Queues
- 吞吐量：
- Kafka 3.5：单分区100万TPS（via NVMe+零拷贝），单集群可处理PB级/天。
- Pulsar：分层存储（热数据存内存，冷数据存S3），无限积压无需扩容。
Cheat Sheet（2025年关键数字）
| 组件 | 2025年上限 | 旧认知（2020） | 影响 |
|---|---|---|---|
| 单实例内存 | 12TB（云实例） | 500GB | 减少分片需求 |
| 单盘SSD | 100TB，百万IOPS | 10TB，10万IOPS | 数据库无需分布式 |
| 网络延迟 | 同区域<0.1ms，全球<50ms | 同区域1ms | 缓存可全球化 |
Common Mistakes In Interviews
-
Premature Sharding（过早分片）
- 错误：“用户表有10亿条记录，必须分片！”
- 正确：“2025年PostgreSQL单机可存100TB，先垂直扩容到极限再分片。”
-
Overestimating Latency（高估延迟）
- 错误：“跨AZ调用需要100ms，必须本地缓存。”
- 正确：“2025年云内网跨AZ<1ms，可直接调用。”
-
Over-engineering for High Write Throughput（过度设计高写入）
- 错误：“每秒10万写入，需要Kafka+Spark流处理。”
- 正确：“单机Redis可处理100万TPS，先评估是否真的需要流式框架。”
Conclusion
2025年的硬件能力让**“简单设计”成为最优解**。面试中，用现代数字反驳过度复杂的方案：
- **“单实例+SSD”**替代“分布式数据库”
- **“全球CDN缓存”**替代“多级本地缓存”
- **“Kafka单分区”**替代“流处理集群”
最终目标：展示你基于2025年硬件的务实权衡，而非背诵2020年的教科书。