最近有些朋友在找工作，不少人倒在 System Design 这一轮上。我作为面试者和面试官都参加过 System Design 的面试活动，就写篇博客聊一下我觉得 SD 面试有用的 tips。 首先明确两个事实： 面试的时候，人或多或少都有压力。人在压力下就会忘记东西，或者动作变形。 面试官多数情况比你考虑得点要多，不一定是因为他们水平比你高，而是因为他们的问你的问题可能已经问过其他人无数遍了。可能他挖了很多”坑“等着你跳。 针对第一点，我的应对方法是形成自己的一个 固定的 routine。久而久之形成习惯了，就变成下意识的动作了。这样我就尽可能的不会错过重要的点。我一般都是按照这种次序做 SD 的面试的。 理清楚需求 SD 面试常见的题目就是一开始用一两句简单的话说出一个需求，然后让你设计一个系统去满足。为了考察面试者理清楚需求的能力，面试官都会讲得非常简单。这个时候，需要你通过不断提问的方式从面试官嘴里”挖“出他的真实意图。如果面试者碰到过网上同样的题目，然后直接就略过了这一步，那么恭喜你，这一轮面试你很难通过。 我一般从功能性需求出发，尝试去了解面试官到底想要什么，以及整个业务流程是怎么样的。我记得我参加一个一次面试，面试官要我们设计一个网上商城卖书。我问了很多问题，其实有一个问题是，我说这些书是哪里来的，是先买好了库存还是怎么样？这个时候面试官邪魅一笑，说库存是每天晚上从出版社通过上传 Excel 的方式录入到系统中的。很显然，如果我不问，他肯定不会主动告诉我的。 除了功能性需求以为，我也会尝试着问问一些非功能性需求，比如整个系统是对外的还是内部系统，需要鉴权或者登陆什么的吗。 聊一下系统容量 理清楚需求以后，最好问一下系统预估的容量是多少，比如有多少用户，多少商品，等等等。这个一般涉及到存储的选择 定义系统接口和业务 entity 一个系统总需要和外部交互，就需要提供接口。这里的接口可以一般是一些 HTTP 的接口，也有可能是消息队列的 schema。我在这里说的是接口而不是具体实现。比如如果设计一个用户中心，我就会说我会提供一个接口，客户端可以 create a new user with these properties。到这一步，我不会具体说，我要实现用 Restful 或者 RPC 的方式实现一个创建用户。我就碰到过面试者，在设计接口的时候，默认选择 Restful API，然后花很多时间去讲一些细节，结果没有时间和面试官讨论其他的东西。同样，了解完业务以后，系统中一定会有一些实体（entity）的。我一般根据我的理解，把业务实体给写下来，每个实体有哪些哪些字段。和接口一样，我不会说这些实体我需要用什么数据库保存。我只会和面试官说，我的系统里面有这些实体，我会把他们存在某个存储中。 如果这个时候，有时候有一些面试官会想和我聊一下细节，比如用什么数据库等等。我都会说，让我们先把高层的设计做完在去讨论某些细节。这样面试的节奏一直是自己熟悉的节奏，也显得我比较有信心。 画一个高层的架构图 到了这一步，我基本上脑子里面有个大致的架构图，这个时候我会用一个画图软件把这个架构图给画出来，我一边用Excalidraw这个网站。注意，在架构里面，我也没有指明任何任何具体的技术栈，数据库就是数据库，而不是 MySQL 或者 Redis 什么的。把这个高层的架构图给画出来以后，我会把一个业务流程的数据流给面试官讲解一下。比如如果创建一个用户，首先由 client 发起一个请求，服务随后写入数据库，然后发一条消息等等。 […]