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,理论上都不一定是最优。追求这种最优实际上没有多大的意义。很多时
: 候尤其是大数据的时候，往往考虑的更多是如何去建立这种冗余，虽然多费点空间但是
: 性能大大提高。
: 所以你转行没学好传统的数据库影响不大
|
