fb挂经

两轮coding：alien dict两题， robot room cleaner和一道easy的binary search

您好！
本帖隐藏的内容需要积分高于 188 才可浏览
您当前积分为 0。
使用VIP即刻解锁阅读权限或查看其他获取积分的方式

游客，您好！
本帖隐藏的内容需要积分高于 188 才可浏览
您当前积分为 0。
VIP即刻解锁阅读权限 或 查看其他获取积分的方式
Unlock interview details and practice with AI
Curated Interview Questions from Top Companies

怎么优化？
我感觉periodic pull肯定不行吧，所以只能push啊。

我大致来讲一下吧，表面上这是一个FE问题，实际上牵扯到的是后端如何规避spike qps的问题。每时每刻都有人在上下线，假如你有10M的用户在线，即便你把时间线错开，然后拉平到1分钟(即使这个feature对delay再不敏感，你总不能朋友下线超过1分钟还是不显示吧，因为实际上你如果有显示朋友离线功能，最近的显示方式也是一分钟以内这样。)那么你的qps还是要接近10M/60 = 0.13M QPS。这已经是一个很恐怖的并发了。所以说像这种问题，尤其是对于用户以亿计算的公司，一定不会选择polling的solution。push的思路相对来说比较简单，你用一个cache池子记录一分钟的变化，如果你1分钟以内又上线了，就把你从池子里面移除，一分钟以后整理一个list，谁离线了，然后通过relation graph找到所有在线的好友，push notification，这样最大的好处是，这个只牵扯到发送，毕竟你poll的过程是一接一送，push只需要定期推送就可以了，其次那些本身好友在线状态无变化的用户就不需要做推送，就省下了很多不必要的推送。这个问题背后可能还牵扯到产品线和log线关联的问题，比如如何知道一个用户离线了。因为你登录登出其实是一个log信息，有些会选择在log服务器端做handle，直接进行batch处理，定期告知在线状态micro serve，有的可能会是独立的，和log分离。具体设计要看运用场景

convexopt 发表于 2020-5-10 12:13
哈哈实践是检验真理的唯一标准，打开fb用浏览器dev tool看看，只有messenger的聊天信息是websocket推下来的 ...

fb聊天的在线状态也是走的ws（开着devtool让朋友上了一下线）
看这个message结构应该是server端做了batching不是一个一个上下线都单独notify。这里array里面有uid, presence_state, timestamp

可以参照这篇blog，https://www.facebook.com/notes/f ... cenes/496077348919/ 大致思路就是batch

这个系统设计看上去好像更像一个产品设计。
你面的是product API design(pirateX)还是system design(pirate)?

应该可以采取下线后不用立即发Notification，而是等个一段时间，例如从1s到60s内取个随机数发送，这样就可以避免同时发送，降低服务器的压力

可以请问下楼主的timeline吗？谢谢

哈哈实践是检验真理的唯一标准，打开fb用浏览器dev tool看看，只有messenger的聊天信息是websocket推下来的，还是有很多传统ajax polling的。上下线这种事件，不需要追求边缘触发的实时性，即使用长连接推送也可以用batching来减少推送的次数

cjlm007 发表于 2020-5-10 11:49
这个系统设计看上去好像更像一个产品设计。
你面的是product API design(pirateX)还是system design(pirat ...

不清楚啊 应该是system design

fir925 发表于 2020-5-10 12:11
应该可以采取下线后不用立即发Notification，而是等个一段时间，例如从1s到60s内取个随机数发送，这样就可 ...

不太理解这样为什么能降低压力，下线的人数还是不变的，所以要notify的人数也是不变的，这样只是在时间上位移了一下而已吧

timeline日期不太记得了。电面完一周出了结果，然后onsite完1周半出了结果。

convexopt 发表于 2020-5-10 12:13
哈哈实践是检验真理的唯一标准，打开fb用浏览器dev tool看看，只有messenger的聊天信息是websocket推下来的 ...

sounds about right.
现在想想pull确实也行吧 时间间隔长一点就行