m********l 发帖数: 791 | 1 小弟有几年经验,但基本都是别人design好了我去implement。确实系统设计经验不足
又碰到非套路题 只能全程懵逼+跪了
给了题目:
一个游乐场,游客可以standby等游戏,也可以取票然后回过头再来。
限制1:取票的游客最多只能取一个游戏的票 (每张票有时限)
限制2:每个游戏有不同的出票数量限制
好,开始设计吧。。
让我花了个database在白板,问面试官是要设计schema么?他说我们就是聊天,聊聊游
乐场= =
还问了一个如果最后只有一张票了,两个游客同时取票,怎么办?我回答lock,
transaction什么的,其实很虚,两个东西我基本没啥经验。。(经验就是如果不太会
的真的就尽量别提了。。但是不提也什么都说不出来。。很受伤)
有感系统设计这东西,肚子里没货的一下子就看出来了。。像这样的题目面试官聊聊+
面试+抠细节的这种,碰到了就是跪
版上的大神有什么建议么。。。 |
f*********r 发帖数: 7485 | 2 这不很简单吗,就是排队拿号,这些限制加在拍好程序里就可以了啊。比如时间,限制
一个人一张票,票就实名制,领了票还有效的就不给票就是了啊
游乐场人有不多,随便怎么搞就可以了,都不需要分布式
足
【在 m********l 的大作中提到】 : 小弟有几年经验,但基本都是别人design好了我去implement。确实系统设计经验不足 : 又碰到非套路题 只能全程懵逼+跪了 : 给了题目: : 一个游乐场,游客可以standby等游戏,也可以取票然后回过头再来。 : 限制1:取票的游客最多只能取一个游戏的票 (每张票有时限) : 限制2:每个游戏有不同的出票数量限制 : 好,开始设计吧。。 : 让我花了个database在白板,问面试官是要设计schema么?他说我们就是聊天,聊聊游 : 乐场= = : 还问了一个如果最后只有一张票了,两个游客同时取票,怎么办?我回答lock,
|
H**********5 发帖数: 2012 | 3 跟刷算法一样,也是有套路的,建议去一亩三分地把flag所有的system design网页搜
集全,一个一个看。我看了下还是有规律可以总结的 |
h*******0 发帖数: 270 | 4 同时取票 用lock transaction什么没问题啊。。 有什么虚的 |
r*****s 发帖数: 1815 | 5 能咋办 你自己先写一个这个试试吧。。
如果这个系统都做不好的话。。。 那确实是经验太少了点。。。
bs那些估计读了作用也不大。。 |
c*******e 发帖数: 373 | 6 游乐场取票不用排队的?怎么可能出现两个人同时取票的情况? |
j*****8 发帖数: 3635 | 7 两个窗口取票呢。。
【在 c*******e 的大作中提到】 : 游乐场取票不用排队的?怎么可能出现两个人同时取票的情况?
|
r*****s 发帖数: 1815 | 8 。。。。
你没去拿过fast pass么。。。
: 游乐场取票不用排队的?怎么可能出现两个人同时取票的情况?
【在 c*******e 的大作中提到】 : 游乐场取票不用排队的?怎么可能出现两个人同时取票的情况?
|
f*********r 发帖数: 7485 | 9 看楼主是认真问问题,我就说细一点吧,估计就是面试的人想听的
1. 实名制不对,因为有人同名,所以要顾客进门的时候就要领一个ID来确认客人。可
以发门票给客人,每天发出去的门票号都不重样,这样就用数字来确认客人
2. 建数据表的时候,a)每个景点发了什么票,给谁了 b) 每个客人已经领到的票 都存
一份,这样虽然信息有冗余,但是一个人领票,要去查这个人是不是已经领到票就方便
很多
3. 这个游乐场很简单,就是很多client(每个景点一个终端)链接一个总服务器,每
个人连入的时候要同步(锁)。游乐场人数有限,一个server就够了
如果人非要问考虑人暴多景点暴多的情况,就要考虑怎么用分布式并行处理
【在 f*********r 的大作中提到】 : 这不很简单吗,就是排队拿号,这些限制加在拍好程序里就可以了啊。比如时间,限制 : 一个人一张票,票就实名制,领了票还有效的就不给票就是了啊 : 游乐场人有不多,随便怎么搞就可以了,都不需要分布式 : : 足
|
z*********n 发帖数: 1451 | 10 我的理解这题本质是一个基于ticket(token)实现的rate limiter。然后加入一些并发
的考虑。 |
m********l 发帖数: 791 | 11 因为我之前特意看过rate limiter的实现,在面试中也提到了rate limiter,但是rate
limiter的主要作用还是在一定时间内不能做同样的事情超过多少次
面试官说我这里的要求就每个游客不能超过一张票,否决了我rate limiter的提议,然
后我就成无头苍蝇了。。。
【在 z*********n 的大作中提到】 : 我的理解这题本质是一个基于ticket(token)实现的rate limiter。然后加入一些并发 : 的考虑。
|
m********l 发帖数: 791 | 12 你的回答真好 谢谢!
如何建数据表是我的弱项,转行没好好学数据库。每次让建表心里都好虚,觉得是不是
缺了什么信息,是不是没有normalize好,怎么在normalize和de-normalize之间取舍
【在 f*********r 的大作中提到】 : 看楼主是认真问问题,我就说细一点吧,估计就是面试的人想听的 : 1. 实名制不对,因为有人同名,所以要顾客进门的时候就要领一个ID来确认客人。可 : 以发门票给客人,每天发出去的门票号都不重样,这样就用数字来确认客人 : 2. 建数据表的时候,a)每个景点发了什么票,给谁了 b) 每个客人已经领到的票 都存 : 一份,这样虽然信息有冗余,但是一个人领票,要去查这个人是不是已经领到票就方便 : 很多 : 3. 这个游乐场很简单,就是很多client(每个景点一个终端)链接一个总服务器,每 : 个人连入的时候要同步(锁)。游乐场人数有限,一个server就够了 : 如果人非要问考虑人暴多景点暴多的情况,就要考虑怎么用分布式并行处理
|
f*********r 发帖数: 7485 | 13 传统的数据库课程的主要内容是正则化,但是追求正则化实际上没那么重要。你应该知
道即使是BCNF,理论上都不一定是最优。追求这种最优实际上没有多大的意义。很多时
候尤其是大数据的时候,往往考虑的更多是如何去建立这种冗余,虽然多费点空间但是
性能大大提高。
所以你转行没学好传统的数据库影响不大
【在 m********l 的大作中提到】 : 你的回答真好 谢谢! : 如何建数据表是我的弱项,转行没好好学数据库。每次让建表心里都好虚,觉得是不是 : 缺了什么信息,是不是没有normalize好,怎么在normalize和de-normalize之间取舍
|
m********l 发帖数: 791 | 14 对 谢谢。但是考虑游乐场的人数可能不多,面试也可能反击说冗余的话不是single
source of truth啊,会不一致啊什么的。还是要两边都要懂,这样才无懈可击。。
不过话说回来没真正搞过这样的project,确实印象不深。能搞懂最好,搞不懂也只能
学会如何justify自己的解法了
【在 f*********r 的大作中提到】 : 传统的数据库课程的主要内容是正则化,但是追求正则化实际上没那么重要。你应该知 : 道即使是BCNF,理论上都不一定是最优。追求这种最优实际上没有多大的意义。很多时 : 候尤其是大数据的时候,往往考虑的更多是如何去建立这种冗余,虽然多费点空间但是 : 性能大大提高。 : 所以你转行没学好传统的数据库影响不大
|