Senior 职位的系统设计面试到底应该怎么发力?

terry_low38 发表于 2022-8-19 18:40
因为缺少实战训练，你一肚子货不知道怎么倒出来。网上有面试辅导的，花钱请人面试你几次，可以帮你挑问题， ...

+1
首先，我认为这才是正确的解法。我自己是用 interviewing.io 做了几次模拟面试。但我不是给它做广告 我觉得别的途径 比如找个朋友面一下也很重要。
其次，我觉得就是需要找个固定模式去回答 这样好控制时间。比如说一种套路是
* Functional requirements
* Non-functional requirements
* API Design (optional: QPS calculation)
* High-Level Design
  * End to End Flows
  * Schema/Data Structures as needed (optional: storage estimation)
* Deep Dives
最后 我认为。。。还是要背一些答案。。。唉 没办法 应试的本质啊。。。

对于分布式系统设计，其实我认为API设计的意义不是很大，而且很占用时间。如果面试官不问，我就不考虑API设计的部分。其实一个分布式系统设计里面涉及的内容太多，如果是比较senior level的职位，我觉得早点时间进入架构设计比较有用。当然这是个人看法，可能最好能够根据面试的时间来做一下时间分布策略吧。如果总共面试时间是45分钟，这种情况就比较紧张。如果有一个小时，那么时间就充裕一些，可以按照很多书里面的流程来说

一般面试我比较喜欢看candidate 在思考high level的时候有没有也思考细节。也就是所谓的zoom in zoom out。其实在面试的时候我就会说让candidate平时怎么设计的步骤面试就怎么说。但是在说structure的时候就可以开始看candidate有没有兼顾到各种requirement和具体实现会不会有问题。。你可能会说系统设计谁关心implementation detail啊。其实我面试这么多人很多人会在high level上面做想当然的设计。然后我就会问那你这个结构怎么实现呢。绝大部分时候都说不出来。我就会引导问他有什么问题。。

举个简单的例子。让用户给别人的comment upvote或者downvote，然后前端显示vote数量。就像reddit的功能。很自然的用户只能给一个comment upvote一次。不能无限次。首先很多人就会忽略这点。提醒之后就会说哦那我每个comment 在数据库存一个list。里面放vote过的user id。用户vote的时候查一下这个list就行了。聪明的你读到这里别觉得candidate笨。但其实50%的情况都会有人这么说。candidtae如果一开始想到用简单的读写api(再➕个cache估计)来完成这个功能在细节上就会出现这种看似没问题但是其实scale和implementation本身都很麻烦的情况

所以面试的时候我会期待candidtae把结构说出来的时候就有思考可以handle scale吗。或者比如一个api有多个action。(连着call 几个不同的service那中间crash了会有废数据吗。需要idempotency吗)

SD的本质其实看候选人是否对分布式系统有足够的认知，并且对常用组件能够有了解和使用。现在很多SD的面试其实都偏离了这个目的

喜马拉雅疯子 发表于 2022-8-20 10:24
一般面试我比较喜欢看candidate 在思考high level的时候有没有也思考细节。也就是所谓的zoom in zoom out。 ...

这个得结合qps和使用场景来决定的， 对于小型系统直接api读写数据库 其实问题都不大。当然当达到微博系统这种量级的肯定就是不行的

复杂点的就是

服务端接收用户的点赞请求
执行redis脚本，并返回点赞总数信息，redis保存点赞功能的暂时数据
发送普通消息到消息队列
以上两步执行成功后响应点赞完成，否则加入重试队列
重试队列异步重试请求redis或消息队列，直到成功或重试次数用尽
消息队列消费者接收消息，并将消息写入mysql

微博这种量级的优化其实很复杂的，点赞数就是单独的一个service，redis都已经不能满足他们的需求了。

candidtae如果一开始想到用简单的读写api(再➕个cache估计)来完成这个功能在细节上就会出现这种看似没问题但是其实scale和implementation本身都很麻烦的情况  不知道层主这句话是想表达啥，对于基本的upvote/downvote不就是一个api么