第1步 ：需求沟通

把所有需要的东西聚集在一起，审视问题。不停的提问，以至于我们可以明确使用场景和约束。讨论假设。

• 谁会使用它？
• 他们会怎样使用它？
• 有多少用户？
• 系统的作用是什么？
• 系统的输入输出分别是什么？
• 我们希望处理多少数据？
• 我们希望每秒钟处理多少请求？
• 我们希望的读写比率？

架构 CS/BS，客户端/服务端 核心功能要求 QPS 精准性要求 难点分析 询问QPS（日活1000万时≈1200 QPS）、数据量（1TB/天）、延迟要求（P99延迟<200ms） 明确功能：是否需要事务？数据一致性级别？

第2步：架构设计

使用所有重要的组件来描绘出一个高层级的设计。

• 画出主要的组件和连接
• 证明你的想法

模块设计 业务选型 输出架构

第3步：深入设计

对每一个核心组件进行详细深入的分析。举例来说，如果你被问到设计一个 url 缩写服务，开始讨论：

• 生成并储存一个完整 url 的 hash
  • MD5 和 Base62
  • Hash 碰撞
  • SQL 还是 NoSQL
  • 数据库模型
• 将一个 hashed url 翻译成完整的 url
  • 数据库查找
• API 和面向对象设计

​数据流​：客户端请求→API网关→服务→缓存→DB/队列 ​容错设计​：服务熔断（Hystrix）、重试策略（指数退避） ​扩展性​：水平扩展无状态服务，数据库分片动态迁移

第4步：难点优化与扩展设计

​热点Key问题​：本地缓存+随机过期时间 ​分布式ID生成​：Snowflake算法（时间戳+机器ID+序列号） ​全局时钟​：使用NTP+TrueTime（Spanner方案）

确认和处理瓶颈以及一些限制。举例来说就是你需要下面的这些来完成扩展性的议题吗？

• 负载均衡
• 水平扩展
• 缓存
• 数据库分片 论述可能的解决办法和代价。每件事情需要取舍。可以使用可扩展系统的设计原则来处理瓶颈。

第5步：总结

你或许会被要求通过手算进行一些估算。附录涉及到的是下面的这些资源：

• 使用预估计算量
• 2 的次方表
• 每个程序员都应该知道的延迟数