问个snapchat的设计题 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>JobHunting - 待字闺中

问个snapchat的设计题

问个snapchat的设计题# JobHunting - 待字闺中

s*m2015-04-19 07:04

1 楼

和snapchat的story功能有关。
怎么load 每个朋友的story，如果你有3000个朋友都有story，如何Load。
另外每个朋友的story怎么load要保证没有任何delay
---别出看来的面经，就这几句话-----

b*52015-04-19 07:04

2 楼

这个和FB的news feed差不多吧。无非就是两种，一个push model，一个pull
model。有的用hybrid of push and pull
要保证没有任何delay，我觉得只能push了？因为你pull model，是user log on后
，然后去3000个朋友那里query有没有update，怎么样都有delay
push model就是一有user story update，就会broadcast to everyone of his
friends。然后你log on时，就会有一个log，告诉你有多少个new story
generated。。。

【在 s*******m 的大作中提到】

: 和snapchat的story功能有关。
: 怎么load 每个朋友的story，如果你有3000个朋友都有story，如何Load。
: 另外每个朋友的story怎么load要保证没有任何delay
: ---别出看来的面经，就这几句话-----

p*p2015-04-19 07:04

3 楼

抛个砖：
这一般就是起一个DB，开一个events表，关系无非是：
event_id, source_user_id （发起者）, timestamp, is_valid, event_data(json)
由于event基本可以看做immutable，数据库可以设为read uncommitted减少等锁情况
naive solution：
当用户登录时，检索用户好友，然后从events表里，根据timestamp和id，读取所需的
数据（pull），登录以后维持一个tcp长连接，poll或者服务器push最近的更新
当活跃用户多、用户互相之间平均connections多或者该用户经常登录时，上述检索容
易造成第一次登录时更新缓慢甚至超时情况，此时可以考虑push，即给每个用户（或者
部分活跃用户）维护一个event list，naive solution就是再造个source_user_id,
target_user_id, timestamp的表，然后登录时就读这个表获得数据
一个mysql服务器，撑起一个同时在线1000人，平均一人300 connections，和1条event
每人每小时的应用应该还是可以的
考虑到RDBMS的强一致性，不加应用层cache的只靠mysql cache话应该没有延迟
流量上去后这个就需要做sharding，例如根据user_id和活跃程度shard到不同机器上，
或者可以采用应用层cache或者eventually consistent的db（这时肯定有不同程度的
delay，属于trade off了）

【在 s*******m 的大作中提到】