脸家 onsite

楼主在雅图面的吗？

真是厉害！这个是组招吧？

follow up nth tree 怎么答啊？

wangzhuyun32 发表于 2019-4-13 13:31
比如你login了facebook,你的backend system 是如何handle 你的好友的在线和不在线的状态的。

简单的思路：
assumption: 针对的use-case是用户的朋友数量在1~1000个的情况，通常fB也限制朋友的最大数。
1在用户初次登陆的时候：从server读取在线friend的列表，并更新自己的online friend列表。同时，用户的状态由offline变成online也作为statuschange的消息push到server。
2当用户在线使用fB的时候：朋友都有自己的状态，如果一旦发生status change；把status change作为notification push到server，然后转给自己。例如，我正在使用fB，我的页面上显示了目前在线的friend，如果其中某个朋友下线了，他的状态改变会通过notification push到server再转给我，或者直接notify我的client端。

没fB和系统架构的经验，求拍！

wangzhuyun32 发表于 2019-4-13 12:02
在血汗工厂也是组里的主力sdeII, 但今天被脸家的资深中国大哥问的答不上来了。脸家的SDE真是挺强的。
加 ...

楼主能力强，祝马上拿到大包裹!

raincode 发表于 2019-4-13 23:03
follow up nth tree 怎么答啊？

这么做，二叉树的 math.Max(左边最长+右边最长+2) 多茶树，就是loop 一遍找出 math,max(孩子里最长 和第二长的 + 2 )  就行

zorrowei 发表于 2019-4-13 23:20
简单的思路：
assumption: 针对的use-case是用户的朋友数量在1~1000个的情况，通常fB也限制朋友的最大数 ...

你的思路对头。 细节问的很细， 你的列表肯定存在缓存里，比如redis， application server 可以直接fetch, 比如 schema 的设计， web server and data access server , DB and redis 具体如何同步。可以zoom in 的很细。还有
DAU 给我的数据是 1billion 的用户。 我这没设计过tps 这么高的系统。

补充内容 (2019-4-14 00:32):
对了场景，用户比较自由，一会在手机上等，一会在ipad,一会用电脑

感谢分享，两轮sys design是不是至少E5以上的level?

wangzhuyun32 发表于 2019-4-14 00:27
你的思路对头。 细节问的很细， 你的列表肯定存在缓存里，比如redis， application server 可以直接fetch ...

感谢你把系统面试drill into这么细的程度。给我进步思考的信息。

背景：我没有设计和开发分布式系统的经验，目前正在看design data-intesnive application那本书。同时在研究了很多论坛的总结帖子和油管的技术会议视频。我没有太多经验，只能根据看这些资料来讲我的理解了。

1. 缓存： 缓存的使用应该是比较直接，用户登录系统之后，web server通过缓存获取自己全部信息（包括自己所有朋友列表），如果缓存没有，就去route to dB获取用户信息。在得到用户自己的朋友列表之后，再去访问另一个用户状态的缓存服务器（假设存在这样一个用户状态缓存服务器）。假设用户自己和朋友的社交网络graph的地域分布特征为本区域和本国家内的用户的connect较密集，国家之间、洲际之间用户的connect较稀疏； 所以这个用户在线状态缓存，主要保存本地区用户状态。同时少量的其他国家、地区的用户在线状态,方便那些具有多国朋友的人查询自己的好友是否在线。

2. Schema的设计： 这里的schema，我理解的是用户是否在线状态的设计，这个应该是in-Mem的schema-less的JSON对象。如果只是为了online/offline这个应用，在设计schema的时候只需要用少数几个attribute，例如： userID，userName，country，Region etc 这样也可以减少内存需求空间。至于脸书这个社交网络平台的其他schema的设计和考虑就比较宽了，设计的内容太多。

3. web server与data access server的同步：不知道需要讨论那些问题。

4. 数据库与缓存（例如Redis）的同步： 如我上面理解的，用户在线状态信息应该全部通过in-mem获取，如果仅仅是确定在线好友状态，不用去访问关系型数据库（RMDB)。如果是其他信息的话，遵从先缓存更新，后RDMS更新的基本原则。当然需要考虑读/写数据的request load来采取具体策略。

5. 1B的用户数量： 还是需要考虑分片（sharding）。我前面假设脸书的用户具有很明显地域分布特征。在分片的时候，主要考虑把本国本区域的人的在线状态信息存储在附近的datacenter。

这五个方面我的理解肯定都比较肤浅。望楼主多多指教。也方便活跃版面热烈讨论技术的氛围。

zorrowei 发表于 2019-4-18 10:34
感谢你把系统面试drill into这么细的程度。给我进步思考的信息。

背景：我没有设计和开发分布式系统的 ...

@zorrowei 感觉是学霸啊。请问在是在学习还是工作了。如果在找工作又没兴趣来我们组？