s*******m
发帖数: 228 | 1 和snapchat的story功能有关。
怎么load 每个朋友的story，如果你有3000个朋友都有story，如何Load。
另外每个朋友的story怎么load要保证没有任何delay
---别出看来的面经，就这几句话----- | b**********5
发帖数: 7881 | 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*****p
发帖数: 379 | 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 的大作中提到】
: 和snapchat的story功能有关。
: 怎么load 每个朋友的story，如果你有3000个朋友都有story，如何Load。
: 另外每个朋友的story怎么load要保证没有任何delay
: ---别出看来的面经，就这几句话-----
| s**x
发帖数: 7506 | |
|
