logo
Redian新闻
>未名空间
>Living
>
SSN可能被盗用，可以报警？
avatar
SSN可能被盗用，可以报警？# Living
f*a
1 楼
Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
根据你的设计而提出后续问题。）
特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
。
avatar
A*p
2 楼
是马上抓住那孩子的手 组织他的行为
还是等那孩子打完自己家孩子 然后报警
avatar
E*r
3 楼
☆─────────────────────────────────────☆
badcompany (哥玩的不是股票，是心跳！) 于 (Thu Nov 12 19:58:33 2009, 美东) 提到:
看到板上在热烈讨论联储大发钞票会不会引起通胀，会不会制造泡沫等等，实在受不了
。看来很多人完全不理解中央银行控制货币发行的机制。看看我附的图就知道了，虽然
联储很想发钞票，但是这个钞票根本就没发出去。
联储控制发行量的方法是增加银行储备，这是通过公开市场运作进行的。联储向银行买
国债，就把购款贷记银行储备金账户，这样银行就多出一笔储备金，因为储备金是没有
利息的，银行有很强的动机把它借出去，这样贷款就增加了，贷款到了公司或个人手中
，用于投资或消费，经济活动就会增加，所以现代经济的钞票发行主要是通过贷款渠道
，换句话说，没人向银行借钱，这钞票就发不出去，大本还没真的从直升机上扔钞票！
联储可以控制的货币量就是经济里所有的现金加上银行储备，这个总和叫monetary
base,或者叫 high powered money。但是这不是真正的货币总量，真正的货币总量一般
用M2来
avatar
s*0
4 楼
前几天拿着SSN到一个华人超市传真，结果两天过去了对方还是没有收到我的传真。
我便到这个超市，询问是否可以查看传真记录。超市的人坚决说不可以。
不知道是不是他将我的传真，发到他朋友的传真，或者自己电脑上啥的。
觉得可能会盗用我的SSN、拿我的SSN去卖。
我这样的情况报警，有用吗？
avatar
g*u
5 楼
帮顶，求大牛解惑

【在 f********a 的大作中提到】
: Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
: Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
: 序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
: 间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
: 存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
: 根据你的设计而提出后续问题。）
: 特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
: 。
avatar
A*p
6 楼
除了打
遇到很多这种事了
大孩子上来搂自己家孩子脖子
搂的特别紧
我都包子的没去责备
然后我家孩子委屈的哭 我也不知道咋说
avatar
s*l
7 楼
没用，经常查着点credit report吧。
现在什么情况还要传真SSN啊？传真本来就不是安全的方式。
avatar
s*r
8 楼
帮顶！完全不会设计题
avatar
H*5
9 楼
你应该抱住自己家孩子，让拳头落在自己身上，要不就教孩子如何自卫。

【在 A******p 的大作中提到】
: 除了打
: 遇到很多这种事了
: 大孩子上来搂自己家孩子脖子
: 搂的特别紧
: 我都包子的没去责备
: 然后我家孩子委屈的哭 我也不知道咋说
avatar
s*0
10 楼

坑爹的verizon。。。我在电话里讲了SSN，但是非要我传真
觉得超市的人不靠谱，后来我想看看传真记录也不让看。
就担心盗用我信息办卡，转卖

【在 s****l 的大作中提到】
: 没用，经常查着点credit report吧。
: 现在什么情况还要传真SSN啊？传真本来就不是安全的方式。
avatar
h*a
11 楼
随便抛块砖。
如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
要考虑的有以下几点：
1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
uid+updateId)。这些都是我的假设，需要对方confirm。
如果对方认可，那每天需要传送到活跃用户wall上的数据是50Byte * 100M * 50 =
250G bytes ， 约为 3MB/second。考虑到要能处理spike，可以设计传输的capacity为
10MB/second.
存储系统只需存储过去两周的数据，50M * 10 * 50byte = 25GB，考虑peak, 50G，数
据量很小。历史数据暂不考虑。
2）确定采用push 还是pull来发送更新。一般来说用push，但需要比较两种选择各自的
优劣。pull需要对服务器做很多无效的轮询，push相对效率高一些。但要考虑对不活跃
用户和未登录用户不需实时发送（可以backgroud非实时发送），来优化系统。
3）如何发送，一般来说一个更新submit之后，会放到一个Message Queue中，再由一个
publish service (cluster)来一条一条处理。publisher拿到一条message后，根据发
布人的friend list计算出需要deliver到哪些user，然后定位负责deliver到这些user
的服务器，把更新交给他们处理。这里就涉及到暂时过滤掉没有在线的不活跃用户，以
降低需要deliver的数目。所以应该还要设计一个offline的deliver queue, 可以在系
统不繁忙的时候做非实时的delivery。
delivery采用分布式设计，分级结构（比如邮局），可以通过consistent hash迅速定
位到server来处理发送到某个user的message。这里有很多细节可以讨论，比如如何实
现consistent hash，如何group users by their location and select the closest
server to deliver the update, etc.
4）客户端显示更新。每个用户有一个update message queue，存放应该显示给他的
updates。这里可以讨论如何排序这些更新，可以比如根据friend graph先显示重要
friend的更新，也有很多可以讨论的东西。
估算系统需要的服务器数量：
1） Persistent DB storage，数据量25GB－50G，都可以放到内存中。所以一个3个
server的MySQL cluster就够了。一般来说，每个region会有一个自己的cluster，所以
要根据region的数目来估算，比如如果有10个region，就是30台server。
2）publish service也是要分布在不同的region上。假定每个cluster平均负责200M
user，可能需要5台server来处理全部用户，如果10个region，那就是50台server。当
然，这种估算都是很不精确的。要根据具体的情况调整。一般来说都是弹性设计系统，
根据traffic和系统负载随时调整server数量，这里说的只是一个rough的对最大size的
估计。

【在 f********a 的大作中提到】
: Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
: Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
: 序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
: 间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
: 存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
: 根据你的设计而提出后续问题。）
: 特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
: 。
avatar
A*p
12 楼
反应没那么快

【在 H*******5 的大作中提到】
: 你应该抱住自己家孩子，让拳头落在自己身上，要不就教孩子如何自卫。
avatar
b*c
13 楼
没证据没damage，报警没用吧，现在啥都是楼主自己认为的。

【在 s*********0 的大作中提到】
: 前几天拿着SSN到一个华人超市传真，结果两天过去了对方还是没有收到我的传真。
: 我便到这个超市，询问是否可以查看传真记录。超市的人坚决说不可以。
: 不知道是不是他将我的传真，发到他朋友的传真，或者自己电脑上啥的。
: 觉得可能会盗用我的SSN、拿我的SSN去卖。
: 我这样的情况报警，有用吗？
avatar
J*3
14 楼
学习
avatar
t*o
15 楼
这么包子， 确实没什么好说的

【在 A******p 的大作中提到】
: 除了打
: 遇到很多这种事了
: 大孩子上来搂自己家孩子脖子
: 搂的特别紧
: 我都包子的没去责备
: 然后我家孩子委屈的哭 我也不知道咋说
avatar
s*0
16 楼

等有damage了，报警也不管用了吧，而且很麻烦的，汗

【在 b*******c 的大作中提到】
: 没证据没damage，报警没用吧，现在啥都是楼主自己认为的。
avatar
c*a
17 楼
赞半海。
fb最近开发好一个叫虫洞的system，就是您提到的message system，顺便提一下可以拉
拉关系。
avatar
k*b
18 楼
多大的孩。同龄孩子推推拉拉也不用那么紧张。
如果是长期的或者给孩子造成心理阴影的，要重视。
avatar
b*c
19 楼
其实平时经常把SSN信息给出去的。去看个医生，填表的时候SSN加姓名住址还不是都要
给。不见得真是fax的时候给吞了。也许收件方搞错了也有可能。

【在 s*********0 的大作中提到】
:
: 等有damage了，报警也不管用了吧，而且很麻烦的，汗
avatar
c*a
20 楼
所以应该还要设计一个offline的deliver queue, 可以在系统不繁忙的时候做非实时的
delivery－－－－delivery应该always offline。从deliver server一收到ack，然后
就不用管了。
avatar
b*i
21 楼
我回头告诉你。
现在没空。
我正在苦练佛门狮子吼，
清心咒，
移形换影还有隔空点穴。。。

【在 A******p 的大作中提到】
: 是马上抓住那孩子的手 组织他的行为
: 还是等那孩子打完自己家孩子 然后报警
avatar
c*o
22 楼
尤其是TMD有些医生的收据上海拔你的SSN，生日打出来

【在 b*******c 的大作中提到】
: 其实平时经常把SSN信息给出去的。去看个医生，填表的时候SSN加姓名住址还不是都要
: 给。不见得真是fax的时候给吞了。也许收件方搞错了也有可能。
avatar
h*a
23 楼
我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
好。

【在 c******a 的大作中提到】
: 所以应该还要设计一个offline的deliver queue, 可以在系统不繁忙的时候做非实时的
: delivery－－－－delivery应该always offline。从deliver server一收到ack，然后
: 就不用管了。
avatar
l*r
24 楼
不知道怎么说你啊。。孩子都哭了，你还不知道咋说

【在 A******p 的大作中提到】
: 除了打
: 遇到很多这种事了
: 大孩子上来搂自己家孩子脖子
: 搂的特别紧
: 我都包子的没去责备
: 然后我家孩子委屈的哭 我也不知道咋说
avatar
l*s
25 楼
传真后当时就有一份receipt 跟着PRINT OUT
avatar
c*a
26 楼
确实是！！
醍醐灌顶，谢谢大牛！

【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
avatar
k*b
27 楼
可干的太多。
1. 平静地告诉那个孩子你孩子不喜欢这个，请他下次别这么做。
2. 如果不凑效，可以找家长，或者学校老师 complain,请 他们采取措施
3. 如果不行再升级行动，比如叫警察。
你娃委屈哭不一定是被抱了下，而是你消极，不作为的态度。

【在 A******p 的大作中提到】
: 除了打
: 遇到很多这种事了
: 大孩子上来搂自己家孩子脖子
: 搂的特别紧
: 我都包子的没去责备
: 然后我家孩子委屈的哭 我也不知道咋说
avatar
b*c
28 楼
问楼主

【在 l**s 的大作中提到】
: 传真后当时就有一份receipt 跟着PRINT OUT
avatar
a*n
30 楼
以前邻居的一个娃(同胞的),长得特别高大,惯于逗弄tease其他小娃,一次想当着我的面
弄我儿子,我问他,where is your dad? I need to talk to him.(人家娃不讲中文的哦
),然后那小子就灰溜溜地走掉了.
avatar
s*d
31 楼
嗯，得报告FBI，查全国fax哪个收到你的SSN了。
所有fax他们都有记录的。
avatar
z*e
32 楼
这种数据没有必要上db了，nosql就好了
cassandra

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
h*w
33 楼
平静地告诉那个孩子你孩子不喜欢这个，请他下次别这么做。
--意思就是这次打的不能拦，白打了? 怪不得，这么看不惯国内来的＂中国＂人呢，这
样的好＂美国＂人太高大上了。

【在 k******b 的大作中提到】
: 可干的太多。
: 1. 平静地告诉那个孩子你孩子不喜欢这个，请他下次别这么做。
: 2. 如果不凑效，可以找家长，或者学校老师 complain,请 他们采取措施
: 3. 如果不行再升级行动，比如叫警察。
: 你娃委屈哭不一定是被抱了下，而是你消极，不作为的态度。
avatar
s*0
34 楼

当时传真完了，并没有receipt出来，汗

【在 l**s 的大作中提到】
: 传真后当时就有一份receipt 跟着PRINT OUT
avatar
h*a
35 楼
noSql在我看来也是DB了。反正就是个用来做persitence的东东，因为运行时数据都在
内存里了。

【在 z****e 的大作中提到】
: 这种数据没有必要上db了，nosql就好了
: cassandra
:
: timestamp+
avatar
n*2
36 楼
不忍心看你走歪路，特地指点你一下：
要练隔山打牛！

【在 b********i 的大作中提到】
: 我回头告诉你。
: 现在没空。
: 我正在苦练佛门狮子吼，
: 清心咒，
: 移形换影还有隔空点穴。。。
avatar
s*0
37 楼

这个是真的，还是开玩笑？

【在 s**********d 的大作中提到】
: 嗯，得报告FBI，查全国fax哪个收到你的SSN了。
: 所有fax他们都有记录的。
avatar
t*h
39 楼
当场就说：stop it. We don't like it.
然后把自己孩子带走。
事后赵对方家长沟通， 语气要平和客观，尽量不带负面情绪，
让对方家长了解情况，然后他们会看着办。
一般情况下， （我遇到的）都是讲理的家长。人家家长会
用合适的时机来让他们的孩子认识到某些行为是不合适的，
不被欢迎，或者不被父母允许的， 然后孩子就会改正。
（敲木头！）
如果遇到不讲理的家长 （幸亏我还没遇到过，敲木头！），
那么就要采取别的措施了。在学校的话找老师，找校长，
在外面的话，尽量减少跟熊父母的熊孩子一起出现的机会。
实在过分的话，那就找警察了。

【在 A******p 的大作中提到】
: 是马上抓住那孩子的手 组织他的行为
: 还是等那孩子打完自己家孩子 然后报警
avatar
c*o
40 楼
你觉得呢？

【在 s*********0 的大作中提到】
:
: 这个是真的，还是开玩笑？
avatar
w*z
41 楼
用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
到HBase 了。

【在 z****e 的大作中提到】
: 这种数据没有必要上db了，nosql就好了
: cassandra
:
: timestamp+
avatar
t*h
42 楼
我会赶紧上去说： xxx, may I hug you too?
或者, xxx, what's on your shirt?
他就会松开抱紧的孩子，看他的胸口有什么。
然后自己赶紧把自己孩子抱起来。

【在 A******p 的大作中提到】
: 除了打
: 遇到很多这种事了
: 大孩子上来搂自己家孩子脖子
: 搂的特别紧
: 我都包子的没去责备
: 然后我家孩子委屈的哭 我也不知道咋说
avatar
s*0
43 楼

我不知道啊。
如果FBI真查的话，显然能查出来。

【在 c****o 的大作中提到】
: 你觉得呢？
avatar
g*e
44 楼
FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使

【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
avatar
l*g
45 楼
就不能平静但是坚定的说，no, don't do that, this is not right.
然后带自己孩子走开么？
avatar
F*Q
46 楼

FBI才没那么多功夫管这类小事。况且你也没有证据。我觉得没必要想那么多。今后注
意你的credit score就可以了。
当年家里被break-in，被盗了不少东西，玻璃上都有明显的指纹，警察来了也就装模作
样看了看，我问能否检索指纹，他说只有homicide才会。

【在 s*********0 的大作中提到】
:
: 我不知道啊。
: 如果FBI真查的话，显然能查出来。
avatar
z*e
47 楼
如果不用transaction同时不用各种join的话
应该会好点
不过有些框架默认要上transaction，这个很头疼
光是去关掉这个设置就要折腾半天
hibernate就是典型

【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
avatar
t*h
48 楼
一般的小孩，对别人家的大人平静而坚定的口气是不理会的。
下次家长不在的时候，又会去找小孩的麻烦。
所以跟他的父母谈一下，基本上是必要的。

【在 l*****g 的大作中提到】
: 就不能平静但是坚定的说，no, don't do that, this is not right.
: 然后带自己孩子走开么？
avatar
l*o
49 楼
搞笑么。。。
avatar
p*2
50 楼

timestamp+
push的话一般有什么机制？web socket吗？

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
h*w
51 楼
别人一巴掌过来，或者scooter冲过来时能讲这么多？

【在 t***h 的大作中提到】
: 我会赶紧上去说： xxx, may I hug you too?
: 或者, xxx, what's on your shirt?
: 他就会松开抱紧的孩子，看他的胸口有什么。
: 然后自己赶紧把自己孩子抱起来。
avatar
p*g
52 楼
不搞笑,有人真是这样
我以前的rm,要买一个wireless的router,问我说是不是有安全问题.我说一定是存在的,
谁在乎你是谁.然后一个晚上,4处打电话问,无线router是否安全,会不会有人盗用他的
信息,真是一个晚上啊.....
后来他要问一个数据库的问题,我帮他查了,狠认真的告诉他,花了半个多小时.没多久,
他又问了我同样的问题.每次都是一副我不信的样子.第3次问我的同学,第4次又问我,我
火大了,说你是不是有毛病,问这么多次,而且每次都怀疑别人是不是骗他,又要问
毕业了,所有同学都找不到他了,电话,email全换了
可是我还知道他的名字,他的SSN = 我的 +(-) 1

【在 l*****o 的大作中提到】
: 搞笑么。。。
avatar
g*u
53 楼
你们是哪家，twitter也用Cassandra实现的吧？ Facebook 好像用的pull, 存储和查询
用的是一个类似 leveldb的东西，不知道现在还是不是这样的。

用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
到HBase 了。

【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
avatar
t*h
54 楼
我回的是孩子被别的大一点孩子抱紧了怎么办。
要是scooter冲上来，肯定是拉开自己孩子，或者用胳膊挡，或者用脚踹，
看当时的本能反应了，很可能来不及想。
一巴掌上来，能挡就挡。

【在 h**w 的大作中提到】
: 别人一巴掌过来，或者scooter冲过来时能讲这么多？
avatar
c*o
55 楼
贴出他的SSN来，大家帮你人肉

的,

【在 p**********g 的大作中提到】
: 不搞笑,有人真是这样
: 我以前的rm,要买一个wireless的router,问我说是不是有安全问题.我说一定是存在的,
: 谁在乎你是谁.然后一个晚上,4处打电话问,无线router是否安全,会不会有人盗用他的
: 信息,真是一个晚上啊.....
: 后来他要问一个数据库的问题,我帮他查了,狠认真的告诉他,花了半个多小时.没多久,
: 他又问了我同样的问题.每次都是一副我不信的样子.第3次问我的同学,第4次又问我,我
: 火大了,说你是不是有毛病,问这么多次,而且每次都怀疑别人是不是骗他,又要问
: 毕业了,所有同学都找不到他了,电话,email全换了
: 可是我还知道他的名字,他的SSN = 我的 +(-) 1
avatar
s*u
57 楼
起码可以跟对方说no 你这样弟弟or妹妹会痛 不可以！

【在 k******b 的大作中提到】
: 可干的太多。
: 1. 平静地告诉那个孩子你孩子不喜欢这个，请他下次别这么做。
: 2. 如果不凑效，可以找家长，或者学校老师 complain,请 他们采取措施
: 3. 如果不行再升级行动，比如叫警察。
: 你娃委屈哭不一定是被抱了下，而是你消极，不作为的态度。
avatar
p*g
58 楼
你狠

【在 c****o 的大作中提到】
: 贴出他的SSN来，大家帮你人肉
:
: 的,
avatar
w*j
59 楼

那么现在用什么做了？请教啊....

【在 g**e 的大作中提到】
: FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
avatar
k*b
60 楼
你当然可以拦，你啥都可以做，你拿把枪打死人都可以。 自己承担后果就可以了。

【在 h**w 的大作中提到】
: 平静地告诉那个孩子你孩子不喜欢这个，请他下次别这么做。
: --意思就是这次打的不能拦，白打了? 怪不得，这么看不惯国内来的＂中国＂人呢，这
: 样的好＂美国＂人太高大上了。
avatar
s*0
61 楼

已经给收件方打了十几个电话，收件方确实没收到。
但是当时的确传真完成了

【在 b*******c 的大作中提到】
: 其实平时经常把SSN信息给出去的。去看个医生，填表的时候SSN加姓名住址还不是都要
: 给。不见得真是fax的时候给吞了。也许收件方搞错了也有可能。
avatar
z*e
62 楼
cassandra就是facebook自制的nosql，后来贡献给apache了
如果不是cassandra的话，我觉得前面某人说的换hbase的可能性更大

【在 w******j 的大作中提到】
:
: 那么现在用什么做了？请教啊....
avatar
h*w
63 楼
当然，管理员不就做了，也没坐牢。开枪打死人没事的例子也有。
个人造业个人担，任人给自己孩子一个嘴巴，或是撞个大马趴，事后嘴炮一下也是个选
择。同样也自己承担后果就是了。

【在 k******b 的大作中提到】
: 你当然可以拦，你啥都可以做，你拿把枪打死人都可以。 自己承担后果就可以了。
avatar
b*c
64 楼
别纠结了，搞个credit monitor的program开始盯着吧。

【在 s*********0 的大作中提到】
:
: 已经给收件方打了十几个电话，收件方确实没收到。
: 但是当时的确传真完成了
avatar
s*r
65 楼
post to web service

【在 p*****2 的大作中提到】
:
: timestamp+
: push的话一般有什么机制？web socket吗？
avatar
p*g
66 楼
有10几个电话的功夫，搞个credit monitor早就结了，唉，就是想不开

【在 b*******c 的大作中提到】
: 别纠结了，搞个credit monitor的program开始盯着吧。
avatar
l*t
67 楼
now hbase. Cassandra was out. this is old news.

【在 g**e 的大作中提到】
: FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
avatar
d*0
68 楼
见过类似的人。　是有心理问题的。　这种毛病也可能是遗传的。

的,

【在 p**********g 的大作中提到】
: 不搞笑,有人真是这样
: 我以前的rm,要买一个wireless的router,问我说是不是有安全问题.我说一定是存在的,
: 谁在乎你是谁.然后一个晚上,4处打电话问,无线router是否安全,会不会有人盗用他的
: 信息,真是一个晚上啊.....
: 后来他要问一个数据库的问题,我帮他查了,狠认真的告诉他,花了半个多小时.没多久,
: 他又问了我同样的问题.每次都是一副我不信的样子.第3次问我的同学,第4次又问我,我
: 火大了,说你是不是有毛病,问这么多次,而且每次都怀疑别人是不是骗他,又要问
: 毕业了,所有同学都找不到他了,电话,email全换了
: 可是我还知道他的名字,他的SSN = 我的 +(-) 1
avatar
w*j
69 楼
我听说的是，facebook从来也没用cassandra做news feed啊，以前只是用它做inbox
search，现在用hbase来做了，和news feed没关系啊.....
avatar
C*e
70 楼
verizon...
不知道这家脑残怎么想的。。
当时网上order iphone contract free, 网上填了ssn还不算数，一定要fax，然后到
local verizon店里给fax过去了
后来过两天这家混蛋竟然把我的order reject掉了。。。。
从此以后不断收到v家各种广告

【在 s*********0 的大作中提到】
:
: 已经给收件方打了十几个电话，收件方确实没收到。
: 但是当时的确传真完成了
avatar
f*a
71 楼
大牛啊。多谢！

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
b*c
72 楼
verizon那么NC的话，楼主的fax没准其实受到了...

【在 C*******e 的大作中提到】
: verizon...
: 不知道这家脑残怎么想的。。
: 当时网上order iphone contract free, 网上填了ssn还不算数，一定要fax，然后到
: local verizon店里给fax过去了
: 后来过两天这家混蛋竟然把我的order reject掉了。。。。
: 从此以后不断收到v家各种广告
avatar
f*a
73 楼
半海，能否讲讲设计photo sharing和news feed的区别？

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
c*o
74 楼
也这么认为。。。很难找到比Verizon更NC的客户服务了。。。

【在 b*******c 的大作中提到】
: verizon那么NC的话，楼主的fax没准其实受到了...
avatar
Y*f
75 楼
没有登录的用户为啥还要update，难道不是用户登录的时候在临时生成页面吗？

【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
avatar
s*0
76 楼

当时我换carrier到verizon的时候，v家让我传真驾照，40分钟左右就收到了。
这回，v家的credit department无数人去查看了，已经5天了，还没收到，应该就是没
收到。
若是verizon收到没看到就算了，就担心华人超市拿资料去卖。
社安卡上有名字、地址、社安号。囧
今晚还收到封Verizon的邮件，说:"
Do Not Solicit.You don't have to keep calling in, I will go ahead and keep a
close eye on your account and send you a text message once your social has
been updated. "
坑爹啊，都不给反应了。
不知道警察介入会是怎样处理？
重点在于：超市的人会狡辩称就是按照我给的号码输入的。。现在小纸条没有了，传真
记录也不给看，很难界定是否故意截留我的SSN。

【在 b*******c 的大作中提到】
: verizon那么NC的话，楼主的fax没准其实受到了...
avatar
x*0
77 楼
mark
avatar
s*0
78 楼

弄了，钱都付了，但是帐号不能登录，其中Experian家客服说居住地址有问题。
现在想付费弄个credit monitor，三家公司，一家弄不起来，囧
当时申请信用卡时，银行工作人员将我地址搞错，重寄，再更正，导致现在有3个地址。
在注册完登录进去的时候，总是说有技术原因，不能在线拉出我的信用报告（不知道是
不是设置了90天fraud alert的缘故），所以盯不了。
（ps：如果信用被盗，这么短时间也来不及redirect我的address）

【在 b*******c 的大作中提到】
: 别纠结了，搞个credit monitor的program开始盯着吧。
avatar
v*n
79 楼
mark

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
b*n
80 楼
赞！ｍａｒｋ
avatar
B*g
81 楼
换的原因是。。。？

【在 l*****t 的大作中提到】
: now hbase. Cassandra was out. this is old news.
avatar
u*o
82 楼
mark一下
avatar
h*p
83 楼
mark学习
avatar
s*d
84 楼
mark
avatar
x*0
85 楼
mark
avatar
f*a
86 楼
Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
根据你的设计而提出后续问题。）
特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
。
avatar
g*u
87 楼
帮顶，求大牛解惑

【在 f********a 的大作中提到】
: Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
: Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
: 序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
: 间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
: 存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
: 根据你的设计而提出后续问题。）
: 特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
: 。
avatar
s*r
88 楼
帮顶！完全不会设计题
avatar
h*a
89 楼
随便抛块砖。
如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
要考虑的有以下几点：
1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
uid+updateId)。这些都是我的假设，需要对方confirm。
如果对方认可，那每天需要传送到活跃用户wall上的数据是50Byte * 100M * 50 =
250G bytes ， 约为 3MB/second。考虑到要能处理spike，可以设计传输的capacity为
10MB/second.
存储系统只需存储过去两周的数据，50M * 10 * 50byte = 25GB，考虑peak, 50G，数
据量很小。历史数据暂不考虑。
2）确定采用push 还是pull来发送更新。一般来说用push，但需要比较两种选择各自的
优劣。pull需要对服务器做很多无效的轮询，push相对效率高一些。但要考虑对不活跃
用户和未登录用户不需实时发送（可以backgroud非实时发送），来优化系统。
3）如何发送，一般来说一个更新submit之后，会放到一个Message Queue中，再由一个
publish service (cluster)来一条一条处理。publisher拿到一条message后，根据发
布人的friend list计算出需要deliver到哪些user，然后定位负责deliver到这些user
的服务器，把更新交给他们处理。这里就涉及到暂时过滤掉没有在线的不活跃用户，以
降低需要deliver的数目。所以应该还要设计一个offline的deliver queue, 可以在系
统不繁忙的时候做非实时的delivery。
delivery采用分布式设计，分级结构（比如邮局），可以通过consistent hash迅速定
位到server来处理发送到某个user的message。这里有很多细节可以讨论，比如如何实
现consistent hash，如何group users by their location and select the closest
server to deliver the update, etc.
4）客户端显示更新。每个用户有一个update message queue，存放应该显示给他的
updates。这里可以讨论如何排序这些更新，可以比如根据friend graph先显示重要
friend的更新，也有很多可以讨论的东西。
估算系统需要的服务器数量：
1） Persistent DB storage，数据量25GB－50G，都可以放到内存中。所以一个3个
server的MySQL cluster就够了。一般来说，每个region会有一个自己的cluster，所以
要根据region的数目来估算，比如如果有10个region，就是30台server。
2）publish service也是要分布在不同的region上。假定每个cluster平均负责200M
user，可能需要5台server来处理全部用户，如果10个region，那就是50台server。当
然，这种估算都是很不精确的。要根据具体的情况调整。一般来说都是弹性设计系统，
根据traffic和系统负载随时调整server数量，这里说的只是一个rough的对最大size的
估计。

【在 f********a 的大作中提到】
: Facebook 每天有5亿活跃用户。每个用户可以更新自己的状态消息。当用户登录
: Facebook时，”新鲜事“会显示用户好友们最近两周内的状态消息。消息为纯文本，顺
: 序主要由时间决定，但是也受到好友关系，消息重要性，好友当前消息和上一条消息的
: 间隔，等等的因素影响。试设计”新鲜事“功能的系统架构。假设每台服务器有64GB内
: 存，2TB硬盘，试估算该系统总共需要多少服务器。（这仍然是一个开放性的问题，会
: 根据你的设计而提出后续问题。）
: 特别最后估计多少服务器。俺和一哥们儿都挂在这上面了，真悲剧。搞个相关链接也行
: 。
avatar
J*3
90 楼
学习
avatar
c*a
91 楼
赞半海。
fb最近开发好一个叫虫洞的system，就是您提到的message system，顺便提一下可以拉
拉关系。
avatar
c*a
92 楼
所以应该还要设计一个offline的deliver queue, 可以在系统不繁忙的时候做非实时的
delivery－－－－delivery应该always offline。从deliver server一收到ack，然后
就不用管了。
avatar
h*a
93 楼
我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
好。

【在 c******a 的大作中提到】
: 所以应该还要设计一个offline的deliver queue, 可以在系统不繁忙的时候做非实时的
: delivery－－－－delivery应该always offline。从deliver server一收到ack，然后
: 就不用管了。
avatar
c*a
94 楼
确实是！！
醍醐灌顶，谢谢大牛！

【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
avatar
z*e
96 楼
这种数据没有必要上db了，nosql就好了
cassandra

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
h*a
97 楼
noSql在我看来也是DB了。反正就是个用来做persitence的东东，因为运行时数据都在
内存里了。

【在 z****e 的大作中提到】
: 这种数据没有必要上db了，nosql就好了
: cassandra
:
: timestamp+
avatar
w*z
99 楼
用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
到HBase 了。

【在 z****e 的大作中提到】
: 这种数据没有必要上db了，nosql就好了
: cassandra
:
: timestamp+
avatar
g*e
100 楼
FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使

【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
avatar
z*e
101 楼
如果不用transaction同时不用各种join的话
应该会好点
不过有些框架默认要上transaction，这个很头疼
光是去关掉这个设置就要折腾半天
hibernate就是典型

【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
avatar
p*2
102 楼

timestamp+
push的话一般有什么机制？web socket吗？

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
g*u
103 楼
你们是哪家，twitter也用Cassandra实现的吧？ Facebook 好像用的pull, 存储和查询
用的是一个类似 leveldb的东西，不知道现在还是不是这样的。

用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
到HBase 了。

【在 w**z 的大作中提到】
: 用MySQL 是找死。我们就是用Cassandra 实现这个功能。Facebook 放弃Cassandra ,转
: 到HBase 了。
avatar
w*j
105 楼

那么现在用什么做了？请教啊....

【在 g**e 的大作中提到】
: FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
avatar
z*e
106 楼
cassandra就是facebook自制的nosql，后来贡献给apache了
如果不是cassandra的话，我觉得前面某人说的换hbase的可能性更大

【在 w******j 的大作中提到】
:
: 那么现在用什么做了？请教啊....
avatar
s*r
107 楼
post to web service

【在 p*****2 的大作中提到】
:
: timestamp+
: push的话一般有什么机制？web socket吗？
avatar
l*t
108 楼
now hbase. Cassandra was out. this is old news.

【在 g**e 的大作中提到】
: FB一直到2010年还在用memcached+mysql吧。不过他们就把mysql当key/value store使
avatar
w*j
109 楼
我听说的是，facebook从来也没用cassandra做news feed啊，以前只是用它做inbox
search，现在用hbase来做了，和news feed没关系啊.....
avatar
f*a
110 楼
大牛啊。多谢！

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
f*a
111 楼
半海，能否讲讲设计photo sharing和news feed的区别？

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
Y*f
112 楼
没有登录的用户为啥还要update，难道不是用户登录的时候在临时生成页面吗？

【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
avatar
x*0
113 楼
mark
avatar
v*n
114 楼
mark

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
b*n
115 楼
赞！ｍａｒｋ
avatar
B*g
116 楼
换的原因是。。。？

【在 l*****t 的大作中提到】
: now hbase. Cassandra was out. this is old news.
avatar
u*o
117 楼
mark一下
avatar
h*p
118 楼
mark学习
avatar
s*d
119 楼
mark
avatar
x*0
120 楼
mark
avatar
c*n
121 楼
大牛好像重点讲了怎么设计news feed，但是还是不知道应该怎么样计算需要几个
server,大牛assume一个server可以handle 200M user，面试点时候可以这么assume吗？
我主要是stuck在，计算好了需要多少disk space and thoughput以后，怎么样map 到
多少server呢？
请大牛指点
avatar
h*a
122 楼
你对单机的计算能力要有估算啊。还要考虑比如你的应用是CPU boun d还是memory
bound。原题本身就是很简化的估算一下，现实中肯定要复杂一些。
一般来说， launch之前要做load testing，来confirm你的估算基本上make sense。
作为launch的一部分，要对service cluster，database，甚至上游下游的service set
up metrics来监控load的情况（e.g. CPU, memory, network, etc.)。
service的 设计中一定要考虑到scalability，如果发现初始计划的cluster size无法
handle peak的traffic,就要考虑增加机器的数目。Well designed的service应该是可
以方便的通过增加机器来scale的。Initial的size不能适应实际load的情况是很常见的。
现实中经常会用到auto-scaling，就是在peak和non-peak的时间用不同数目的机器。

吗？

【在 c*********n 的大作中提到】
: 大牛好像重点讲了怎么设计news feed，但是还是不知道应该怎么样计算需要几个
: server,大牛assume一个server可以handle 200M user，面试点时候可以这么assume吗？
: 我主要是stuck在，计算好了需要多少disk space and thoughput以后，怎么样map 到
: 多少server呢？
: 请大牛指点
avatar
z*e
123 楼
mark,赞.真正的大牛才愿意分享.
avatar
s*m
124 楼
inceemental updates (publish) + full/on demand sync (pull)

【在 h*****a 的大作中提到】
: 我说的不是这个意思。我的意思是对活跃用户，update的信息需要实时deliver，对于
: 没有登陆的不活跃用户，update的信息不须实时，可以在比如12个小时之内deliver就
: 好。
avatar
s*m
125 楼
scalable么？

【在 Y********f 的大作中提到】
: 没有登录的用户为啥还要update，难道不是用户登录的时候在临时生成页面吗？
avatar
s*m
126 楼
for 3, be careful with scheduling and resource usage for users with large
amount of connections.

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
r*c
128 楼
这个没有底的，facebook自己也在不停improve
for example，一个信息发布以后当这个信息like量变大的时候，他的score 会变大，
所以不光是news published的时候，而是news score change也会影响。总的来说一般
要scalable都是incremental update，通过event base 来 push到 pub，然后sub方
filter out

timestamp+

【在 h*****a 的大作中提到】
: 随便抛块砖。
: 如你所说，没有标准答案，不同面试官心里可能装着不同的答案，你要尽可能顺着对方
: 思路走。多问问题澄清假设，给出多种选择让对方决定详细说哪一个。
: 其实因为用户的状态更新一旦提交，在整个生命周期就是只读状态，（如果允许删除状
: 态更新的话会增加复杂性，这里暂不考虑）所以处理起来相对复杂性并不高。我觉得需
: 要考虑的有以下几点：
: 1）确定需要处理的数据规模。假定FB有10亿用户，里面有1亿每天登陆的活跃用户需要
: 看到update，平均每个人每天看到50条更新。10亿用户中平均每两周有5000万会发布状
: 态更新，平均每人每周10次，每条更新需要50个字节的存储和传送（内容＋timestamp+
: uid+updateId)。这些都是我的假设，需要对方confirm。
avatar
c*3
129 楼
感觉大牛这点没讲透。能否具体说说一台机器何以处理多少请求？1000人次还是1百万
人次？另外Facebook是用什么作webserver呢？Tomcat?不同的webserver，能力也不一
样。
详细讨论用什么样的机器合适，很有的讨论，但能不能通过面试，可能要看面试官是魏
老师还是goodbug了。站错队，很危险

set
的。

【在 h*****a 的大作中提到】
: 你对单机的计算能力要有估算啊。还要考虑比如你的应用是CPU boun d还是memory
: bound。原题本身就是很简化的估算一下，现实中肯定要复杂一些。
: 一般来说， launch之前要做load testing，来confirm你的估算基本上make sense。
: 作为launch的一部分，要对service cluster，database，甚至上游下游的service set
: up metrics来监控load的情况（e.g. CPU, memory, network, etc.)。
: service的 设计中一定要考虑到scalability，如果发现初始计划的cluster size无法
: handle peak的traffic,就要考虑增加机器的数目。Well designed的service应该是可
: 以方便的通过增加机器来scale的。Initial的size不能适应实际load的情况是很常见的。
: 现实中经常会用到auto-scaling，就是在peak和non-peak的时间用不同数目的机器。
:
相关阅读
天然无污染去油污洗碗液——面汤买房贷款需要货比三家吗？路冲请教怎么杀蚂蚁？没有pay stub, 只有offer letter, 可以贷款买房吗？我是第一个发现每次捡蛋节都是星期天吗?study里的转椅轮子，怎么保护木地板银行WIRE MONEY都要好几天啊请问大家，水泥地有一部分炸裂了怎么办请问最近利率多少啊，中部农村sink下面柜子再下面 的地板如何清理/更换【活动]】征求最新神器1, 2, 3 代, 山寨神2和机械按钮油烟机DI装饰画的质量searspartdirect居然还没关于大绿的滴油？请教一下iMore关于add-a-wireshower head leaking 是找plumber 还是handyman来修求密苏里mortgate quote洗衣机的进水突然变小了曝光两个住在New Prot的人渣－马宁，龚洁明
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章，不代表同意其说法或描述，仅为提供更多信息，也不构成任何建议。文章信息的合法性及真实性由其作者负责，与Redian.news及其运营公司无关。欢迎投稿，如发现稿件侵权，或作者不愿在本网发表文章，请版权拥有者通知本网处理。