Redian新闻
>
twitter这种网站,实现起来的难点在哪?我怎么找不到
avatar
twitter这种网站,实现起来的难点在哪?我怎么找不到# JobHunting - 待字闺中
w*s
1
不就是一个message分发平台么?
随便一个在校生,都能很容易实现的吧,这类pub/sub系统太多了
avatar
z*e
2
恭喜你答对了
本质是米犹的泡沫
没看到卡桑天天在举例么?
avatar
f*h
3
twitter变好的象征就是你见大鲨鱼愈来愈少了 这个在校生做的不会遇到吧
avatar
i*d
4
呵呵,任何小数据的系统都是在校生做得出来的。google你其实也可以做出来。
最后拼的还不就是scale?Friendster为什么最后被facebook干掉了?不就是scale有问
题么?
avatar
n*n
5
忍不住呵呵一下,呵呵呵呵呵呵呵呵,呵呵,呵
avatar
m*l
6
等楼主写好后我给你做个load test, 量不大,不就100w每秒的请求嘛
avatar
m*l
7
设计一个twitter是个经典的面试题,从这题就可以看出面试者是entry level还是
senior architect
avatar
r*s
8
靠,这个真不难,难得的是你能制造100w每秒的请求。
具体讨论一下,怎么搞出来的?

【在 m*****l 的大作中提到】
: 等楼主写好后我给你做个load test, 量不大,不就100w每秒的请求嘛
avatar
s*x
9
the tech in web does not really need super high tech, it is not about the
technology actually, it is about the business model.
walmart has 0 technology, they just hire and sell stuff, but can you build
another walmart in one day?
twitter, facebook, even for g, every one can copy the technology, but it is
not easy to drive online traffic to your site.
intel once a hard core in the tech, see what happened to them?
it is not about technology, it is about the true business.
wall street like new business. why? it is hard to predict !!
avatar
s*e
10
你可以先试着了解微博的应用开发,说大了就是数据的收发,往细了看就会发现东西很多
如何验证,如何请求数据等等。。。。
avatar
z*e
11
呵呵,以前这个主要问题在mysql上
lamp里面最弱的就是m,p也够呛,但是比m强很多
google以前就是p,不过是改造了的p
现在,lyce为代表的bundle上cloud爆20个instances的话
对付100w/s的访问量应该能搞定
yaws单node支撑并发量实测是8w/s,apache只能实现4k/s

【在 i**d 的大作中提到】
: 呵呵,任何小数据的系统都是在校生做得出来的。google你其实也可以做出来。
: 最后拼的还不就是scale?Friendster为什么最后被facebook干掉了?不就是scale有问
: 题么?

avatar
z*e
12
楼主,现在很多master+学生毕业设计就是做大数据并发和挖掘
其中之一就是通过去twitter等网站取数据,处理后集中存放
最后通过统计手段挖掘出信息这么一个过程
这个东西的确不难,以前难主要是db撑不住,还有apache http server也比较弱
但是lyce等新生代为代表的bundle对于大流量并发的支撑大概是lamp的20倍
所以前面说100w很难的,我看未必,倒是你如何造出100w/s这个难度
可能跟你对付处理100w/s这个难度相当,就算用cloud你也要确保你钱够
建议用学校的资源做测试,出来就可以忽悠了
难的在最后一步,也就是用统计来分析数据,这个
呵呵之后还是呵呵
avatar
i*d
13
很简单的一个问题,lady gaga更新了一条tweet,怎么样能够及时显示到所有follower
的首页上?这本质上是个高fanout数据更新的问题。你可以tweak你的后端数据存储和
你的数据pipeline,决定是在读还是写的时候做fanout。和你用php, jsp, Xsp没有任
何关系。

【在 z****e 的大作中提到】
: 呵呵,以前这个主要问题在mysql上
: lamp里面最弱的就是m,p也够呛,但是比m强很多
: google以前就是p,不过是改造了的p
: 现在,lyce为代表的bundle上cloud爆20个instances的话
: 对付100w/s的访问量应该能搞定
: yaws单node支撑并发量实测是8w/s,apache只能实现4k/s

avatar
z*e
14
那个snapchat就是lyce
斯坦福几个学生就创业成功
所以大本跑来忽悠我学erlang
难么?
呵呵
难不难关键在于你去不去做
很多东西都是一个人做的
avatar
e*3
15
能说出walmart零技术含量的话,下面的话就不用看了。

is

【在 s**x 的大作中提到】
: the tech in web does not really need super high tech, it is not about the
: technology actually, it is about the business model.
: walmart has 0 technology, they just hire and sell stuff, but can you build
: another walmart in one day?
: twitter, facebook, even for g, every one can copy the technology, but it is
: not easy to drive online traffic to your site.
: intel once a hard core in the tech, see what happened to them?
: it is not about technology, it is about the true business.
: wall street like new business. why? it is hard to predict !!

avatar
z*e
16
你那么确定他们是即时显示的?
我前几天刚论证了只要是分布式机器,就不存在有真正意义上的real time
因为网络的latency远远大于内存操作
不过这个无关系,我们从最简单的开始,就用最愚蠢的做法,谁都能想到的
100w/s我爆了20个instances,我就用最愚蠢的gossip,挨个拷贝过去
总共也不过20个couchdb么,拷贝过去很慢么?
挨个拷贝过去,直到所有的couchdb都被replicated
20个估计用不了半分钟就能搞定
然后每一个负责的front end对轮询的request做回馈
难么?

follower

【在 i**d 的大作中提到】
: 很简单的一个问题,lady gaga更新了一条tweet,怎么样能够及时显示到所有follower
: 的首页上?这本质上是个高fanout数据更新的问题。你可以tweak你的后端数据存储和
: 你的数据pipeline,决定是在读还是写的时候做fanout。和你用php, jsp, Xsp没有任
: 何关系。

avatar
i*d
17
我没说 即时, 我说的是 及时。
其次,我没有argue 说这个问题解决不了,我只是说这个和你用什么前端半毛钱关系没
有。

【在 z****e 的大作中提到】
: 你那么确定他们是即时显示的?
: 我前几天刚论证了只要是分布式机器,就不存在有真正意义上的real time
: 因为网络的latency远远大于内存操作
: 不过这个无关系,我们从最简单的开始,就用最愚蠢的做法,谁都能想到的
: 100w/s我爆了20个instances,我就用最愚蠢的gossip,挨个拷贝过去
: 总共也不过20个couchdb么,拷贝过去很慢么?
: 挨个拷贝过去,直到所有的couchdb都被replicated
: 20个估计用不了半分钟就能搞定
: 然后每一个负责的front end对轮询的request做回馈
: 难么?

avatar
z*e
18
不是给了你数据么?
php只能支撑4k/s
如果是apache http server的话
100w/s你要开250个instances
你确定250个instance互相拷贝里面不会有问题?
这估计要上paxos了
20个容易多了
如果用主机的话,就更容易了

【在 i**d 的大作中提到】
: 我没说 即时, 我说的是 及时。
: 其次,我没有argue 说这个问题解决不了,我只是说这个和你用什么前端半毛钱关系没
: 有。

avatar
z*e
19
删文干什么?
我好容易回了点文字
你居然删了
我重复一下吧,你说了soa和denormalization
soa不是问题,lyce下你不懂什么是soa一样做,想做错很难
其次denormalization,couchdb不存在这个问题,因为是doc-based
不需要做这一步,跟fb最早用mysql这种table based的db不一样

【在 i**d 的大作中提到】
: 我没说 即时, 我说的是 及时。
: 其次,我没有argue 说这个问题解决不了,我只是说这个和你用什么前端半毛钱关系没
: 有。

avatar
i*d
20
我删文是觉得和你argue这个问题很没有意义。
fanout或者不fanout和你有什么db没有本质关系。你doc-based和无非就是节约写的
cost而牺牲读。你写不用fanout,你读需要fanout了。这个和你的读写qps的pattern有
关。还是那句话,规模大了以后都会出现问题。至于会出现什么问题,我觉得你可以去
看看twitter VP的一个关于fanout的talk。这种问题其实不是一句话两句话可以说清楚
的。一直争论下去只是耽误你我的时间,不如花点时间来好好学习一下这些公司的架构
,来充实自己。

【在 z****e 的大作中提到】
: 删文干什么?
: 我好容易回了点文字
: 你居然删了
: 我重复一下吧,你说了soa和denormalization
: soa不是问题,lyce下你不懂什么是soa一样做,想做错很难
: 其次denormalization,couchdb不存在这个问题,因为是doc-based
: 不需要做这一步,跟fb最早用mysql这种table based的db不一样

avatar
g*g
21
1M的请求很容易做,要撑住很难

【在 r****s 的大作中提到】
: 靠,这个真不难,难得的是你能制造100w每秒的请求。
: 具体讨论一下,怎么搞出来的?

avatar
z*e
22
你自己都搞不清楚问题在哪里
就知道蹦名词,搞得好像很牛逼的样子
你是否意识到了
我给的bundle恰恰就是message oriented middleware
专门用来搞messaging pattern的?就是你这里故弄玄虚的fan-out
如果你真的懂你说的所谓的twitter架构,你应该明白我在说啥
而不是说了半天不着重点,最后说,总之大了就会有问题
我是不应该跟你吵下去,浪费我的时间

【在 i**d 的大作中提到】
: 我删文是觉得和你argue这个问题很没有意义。
: fanout或者不fanout和你有什么db没有本质关系。你doc-based和无非就是节约写的
: cost而牺牲读。你写不用fanout,你读需要fanout了。这个和你的读写qps的pattern有
: 关。还是那句话,规模大了以后都会出现问题。至于会出现什么问题,我觉得你可以去
: 看看twitter VP的一个关于fanout的talk。这种问题其实不是一句话两句话可以说清楚
: 的。一直争论下去只是耽误你我的时间,不如花点时间来好好学习一下这些公司的架构
: ,来充实自己。

avatar
y*u
23
是这片吗?
http://www.infoq.com/presentations/Real-Time-Delivery-Twitter
看了好几次了,还是不太懂

【在 i**d 的大作中提到】
: 我删文是觉得和你argue这个问题很没有意义。
: fanout或者不fanout和你有什么db没有本质关系。你doc-based和无非就是节约写的
: cost而牺牲读。你写不用fanout,你读需要fanout了。这个和你的读写qps的pattern有
: 关。还是那句话,规模大了以后都会出现问题。至于会出现什么问题,我觉得你可以去
: 看看twitter VP的一个关于fanout的talk。这种问题其实不是一句话两句话可以说清楚
: 的。一直争论下去只是耽误你我的时间,不如花点时间来好好学习一下这些公司的架构
: ,来充实自己。

avatar
s*c
24
ladygaga 是所有社交网络的噩梦。
社交网络的workload一般读写比都大于9:1,所以应该是写时fanout吧?

follower

【在 i**d 的大作中提到】
: 很简单的一个问题,lady gaga更新了一条tweet,怎么样能够及时显示到所有follower
: 的首页上?这本质上是个高fanout数据更新的问题。你可以tweak你的后端数据存储和
: 你的数据pipeline,决定是在读还是写的时候做fanout。和你用php, jsp, Xsp没有任
: 何关系。

avatar
w*r
25
中国移动都可以,这个有啥难的

【在 g*****g 的大作中提到】
: 1M的请求很容易做,要撑住很难
avatar
a*l
26
这个说的对。我再重复一下,twitter的难点是找到足够的人产生每秒一百万次的请求。

【在 r****s 的大作中提到】
: 靠,这个真不难,难得的是你能制造100w每秒的请求。
: 具体讨论一下,怎么搞出来的?

avatar
a*l
27
从技术上说,社交网络是最容易scale的应用了。没有互锁,没有实时,没有同时。

follower

【在 i**d 的大作中提到】
: 很简单的一个问题,lady gaga更新了一条tweet,怎么样能够及时显示到所有follower
: 的首页上?这本质上是个高fanout数据更新的问题。你可以tweak你的后端数据存储和
: 你的数据pipeline,决定是在读还是写的时候做fanout。和你用php, jsp, Xsp没有任
: 何关系。

avatar
w*r
28
找机器模拟好了,做压力测试都是找机器模拟的
台式机就可以,数量足够多,网络够就可以了,有啥难的

求。

【在 a****l 的大作中提到】
: 这个说的对。我再重复一下,twitter的难点是找到足够的人产生每秒一百万次的请求。
avatar
y*g
29
他的意思我觉得是找到那么多活跃用户

【在 w****r 的大作中提到】
: 找机器模拟好了,做压力测试都是找机器模拟的
: 台式机就可以,数量足够多,网络够就可以了,有啥难的
:
: 求。

avatar
w*r
30
有这么多活跃用户直接就卖给google好了,还捣鼓啥,直接回家养老了

【在 y*******g 的大作中提到】
: 他的意思我觉得是找到那么多活跃用户
avatar
i*d
32
这个是有道理的。现在更通常的做法是hybrid

【在 s******c 的大作中提到】
: ladygaga 是所有社交网络的噩梦。
: 社交网络的workload一般读写比都大于9:1,所以应该是写时fanout吧?
:
: follower

avatar
z*e
33
对,更没有transaction和金钱交易,不存在丢包风险
基本上都属于堆机器就能搞定的应用
尤其是twitter和facebook
其他电商等网站,都涉及到金钱交易,属于精度要求高的应用
都多多少少卷入db处理,只要卷入db,都属于比较难scale out的应用
多数时候只能scale up,那这个后面做起来就蛋疼了

【在 a****l 的大作中提到】
: 从技术上说,社交网络是最容易scale的应用了。没有互锁,没有实时,没有同时。
:
: follower

avatar
z*e
34
做twitter那帮人他们自己都没想到能做这么大
一开始只是小打小闹的,就有点像当年的ytht.net
最早只是用来给北大物理系内部沟通的工具,后来人数暴涨
不过这个东西来得快去得也快,去年还火的公司,今年就开始裁员了
米犹吹泡泡吹fb,顺便带动了twitter
从这点上看,将来有人也一夜成名,我觉得有可能
大学里老师都是鼓励学生去尝试制作一个twitter出来
作为练习,同时也鼓励学生创业
技术上,社交网站不存在难点,同等用户量下,社交网站技术难度属于最低一层
电商网站则属于精度要求比较高的一层,大量卷入lock和transaction
which大量实用了互斥锁,事务等机制,导致整个分布式应用不太容易scale out
给学生布置作业都喜欢用twitter,因为简单,学生只需要对付单纯的分布式问题就好了

求。

【在 a****l 的大作中提到】
: 这个说的对。我再重复一下,twitter的难点是找到足够的人产生每秒一百万次的请求。
avatar
P*c
35
你以为是让你做宇宙飞船或者国家机密武器么?
商业社会,大家做的就是协同作战把一个有商业潜力的idea做好做大。你再实现一个
twitter, 能有现在的twitter的影响力吗?有时间不要copy twitter, 多想想有什么更
有潜力的idea.
有技术机密的地方就会有垄断。有垄断的地方就会造成吃老本,底层员工可替代性高。
computer science比较open的氛围正是不断有disruption, 底层员工还比较好过的原因。
很多人不懂得appreciate这点。总想着自己掌握一个其他人都不知道的武林秘籍。练成
了就天下无敌。

【在 w********s 的大作中提到】
: 不就是一个message分发平台么?
: 随便一个在校生,都能很容易实现的吧,这类pub/sub系统太多了

avatar
N*D
36
嗯,不难的,分分钟写一个。

【在 w********s 的大作中提到】
: 不就是一个message分发平台么?
: 随便一个在校生,都能很容易实现的吧,这类pub/sub系统太多了

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。