系统设计专题:Amazon排序系统设计(Mock-interview)
背景:
interviewee面试者背景: 4年经验, 准备面试stripe
interviewer面试官: 来自Amazon
scientiacoder: 科学码农 https scientiacoder io
题目背景:
Amazon有1000 0000个product, 以及1000个categories种类, 每个product可以属于1到n(多)个category.
比如说当你浏览一些商品的时候, 它们是在category内排序的, 比如iphone会在iphones(苹果手机), electronics(电子产品), phones(手机)内部进行排序, 请你设计一个在category内部按照sales(n天内的销售数量)进行排序的系统
开始
interviewee简单的重复了一下问题比如有product_id, 然后API是发送一个category, 返回一个n top hits, 之后又问了关于latency延迟的问题得出了一个新的requirements:
requirements: 这个系统要每个小时hourly更新一次
之后这个interviewee从load balancer(...这里是个坑, 一会说)入手, 开始描述系统的架构, 如下图所示:
图中有这几个组件:
- load-balancer: 负载均衡器, 作为后端流量的入口
- server response: 这个是它的后端服务器server
- redis cache: 缓存存储topK任务
- batch job: 批处理定时任务, 定时从db里拉数据, 然后计算并且将结果写入缓存
- timeseries_db: 时序数据库, 用来存储交易信息
- relational_db: 关系数据库, 用来存储product_info
之后interviewee讲了一下逻辑：既然要根据category里最近n天购买量进行排序, 用一个时序数据库(提了一下Cassandra, 这一点用时序数据库我觉得挺好的)来存交易信息是非常好的, 然后batch job批处理定时从数据库里拉取数据计算, 写入redis
这时候interviewer提出了一个问题: 假如一些人想要添加一个已经有排序信息的item, 你的这个系统支持这个功能吗？比如你在第三方商城有一些物品item, 现在你也想放到Amazon上去卖, 然后你把第三方的一些交易信息提供出来, 可以用这些来代表它的rank吗？
scientiacoder点评: 这是一个好问题, interviewee给出的解法是将这些交易信息添加到timeseries_db中, 然后在下一个batch job运行的时候还是读取n天内的交易信息, 然后更新. 其实可能有更好的解法, 比如用堆来存储topK问题, 然后用新增的这些交易transaction信息直接与堆顶比较, 并且写入到timeseries_db中, 而不是等待下一个batch job(cron)
之后interviewer又提出了一个问题: 你的Redis down了怎么办?(其实是这个架构有单点故障问题)
interviewee回答的是redis down了肯定不能每次都运行batch job，然后返回数据，可以把cache的信息提取出来做持久化，放到数据库里, (但也没说具体是哪个数据库)
之后就进入了写代码的环节，只是简单写出class, function以及参数等即可, interviewee写出了他的代码:
之后就是一些其他的话，以及interviewer对这次面试的反馈总结, 说的挺好的，这里记录下(翻译+scientiacoder校对):
- 确保提出更多澄清的问题(开始时一定不要着急写代码, 一定要把需求，限制, scale扩容之类的搞清楚!!3年工作经验的总是着急写代码这样不好...)，如果您不确定要问的问题，请问，即使还没来得及问，也很容易跳过一些问题，然后不问问题，直到面试和回答他们会给您带来可能更改设计的机会，或更糟糕的是，因为您没有要求他们告诉您一些会破坏您已经进行的设计的东西（故意）
- 进行高级设计时，请确保从请求开始/结束的特定位置开始(这里应该从客户端或者是调用方发起HTTP请求开始，而不是负载均衡)，然后从负载均衡器开始，并且未指定任何有关请求源的信息。这通常是错误的形式，您应该始终从请求源开始。这样做可能会有风险，因为访问员总是可以将其隔离到有关DNS的问题中，但是我认为它看起来不错，并且可以更清楚地了解请求的整个生命周期。您正在建模的信息流
- 计算用量！！您完全跳过了这一部分，我知道这可能会很乏味，但是花2-4分钟来计算该服务将使用多少使用量是值得的，我觉得如果您事先进行了此操作，便会意识到可以进行扩展一次重做就不足以满足每月1000亿个请求的读取需求（大约4万个请求/秒的不均衡流量）
- 陈述您正在做的假设(和interviewer陈述假设)，我觉得您在面试时曾想过一些事情，而您却没有口头谈论这些事情（例如数据库如何将存档的cache存储在单独的表中）对于您的设计，我理解并且暗含了它，但是陈述您所假设的事情很好）。陈述有关流量模式和负载的假设也很不错（例如，我们所讨论的服务之类的服务在一整天都不会出现流量，高峰和波动会非常严重）
PS
从网友的反馈来看, 这个interviewee应该没有过..稍后scientiacoder会放出我的设计, 放在附录里
本文章首发于scientiacoder io, 更多后端(操作系统,数据库,中间件等)深度知识, golang原理等请访问https scientiacoder io 转载请注明scientiacoder io