About Tim Yang

Tim’s Blog, if you want to read the English only posts, please visit https://timyang.net/tag/English/

Westar Labs 创始人、中国计算机学会CCF TF主席。专注技术创新与行业赋能,拥有丰富的互联网架构及管理经验。曾任新浪微博研发副总经理,负责微博整体架构工作。

联系可Email: ,或通过以下方式交流:

  • 微博,@TimYang(V认证);
  • 微信公众号:在公众号搜索“TimYang_net”,或通过页面下方二维码订阅;
  • 在 Twitter 关注  timyangnet,原 xmpp 已经转让给 XMPP Standards Foundation(参看 status);
qrcode_for_timyang_small

如想及时阅读 Tim Yang 的文章,可通过页面右上方扫码订阅最新更新。

|

Comments

91 Comments

  1. zjstandup

    杨老师,您好!
    我们在使用Tokyo Trant存储的时候发现它的IO是一阵一阵的高,比如说平均两秒有一个100的IO,然后又降到10几,这个是我们没有配置好么?

  2. 杨大侠好,前两天在QCon听您的关于新浪微博的分享,由于当时坐的比较靠后,有几个问题没有听清楚,所以再向您请教一下:
    1:新浪微博的memcacheq和twitter的kestrel这种mq是用在什么地方呢?是不是都是用来异步更新follower的timeline?
    2:比如twitter的kestrel,有篇文章里写是当mem满了之后,后续的message写进磁盘,这样的话,如果遇到宕机之类的,在mq中的message就丢失了。新浪是如何处理这种情况的呢?(会上好像听您说用memcache池来避免mq单点,不过没听很清楚,还请劳烦指导一下)

    以上两个问题,如果是属于“有些事不能说太细”的范畴,也烦请稍微暗示下哈~^_^~ 谢谢!
    (如果可以帮忙,烦请回复一下,邮箱[email protected], twitter:@vonbo)

  3. Tim

    vonbo
    1. 用来处理异步业务。比如发表的峰值过大数据库会出现瓶颈,则使用mq能缓解峰值的压力。另外还具有业务解耦等作用。

    2. mq宕机数据不会丢失,它是持久保存的。

  4. dean

    hi,请教关于jwchat 和 openfire。
    1.关于openfire和jwchat的namespace的对应。
    2.有没有jwchat的文档?

    thanks&regards

  5. ciweek

    不知道是否对云计算相关内容感兴趣

  6. chenjun

    杨老师,你好
    能否推荐一个比较成熟的分布式存储(文件)系统(在一个idc机房),要求它能解决单点故障,自动恢复,自动扩展等。谢谢

  7. anderson guo

    Tim yang, 你好

    在QCon 2010 BeiJing上听了你的微博架构,还有些意犹未尽。

    但回过头来发现对于Amazon Dynamo的理解还不深刻,特别是Quorum为什么能够保证分布式下的数据一致性感到迷惑。

    另外,为什么会出现多个节点的同一数据项版本不一致的情况?按照consistent hashing算法,一个key的get/put请求首先会定位到同一个coordinator node,然后由其完成本地读取或者存储后,同时请求存放在preference list中的节点的值的,也就是说,读取应该不会取到旧的数据才对啊。

  8. 今天上www.facebook.com,有幸找到您的博客。06年在深圳清华信息港。标记一下。

  9. 行人

    您好,有没有SAE的邀请吗,怎么能获得?谢谢了。

  10. wind

    不错
    也顶一下

  11. qiutm

    感觉很不错,交个朋友吧,有机会一起创业吧!

  12. 楼主这里的文章都是干货

    学到不少东西…

  13. justforfun

    博主好,我想咨询个问题:
    sina微博的关注和被关注人数有限制吗?比如如下两种情况:
    1.我关注了1亿个用户
    2.有1亿个用户关注我。

    那么如果是这种变态的情况,动态信息推送是怎么实现的?

    我写了一条信息,要推送给所有的粉丝?(推)
    还是推拉相结合,然后找一个平衡点?

    还有你们的微博系统,单台服务器大约能支持多少条消息并发?

    谢谢!!!

  14. Tim

    justforfun:

    关注上限目前是2000,不存在你说的情况。
    其他信息可关注我博客中分享的ppt

  15. opsfans

    No.18 Follow Cost: 7.193143 s, Each: 2.702145 s, Runtime: 52 s.
    Process fans of 1253491601_1797330643 … Successful.

    No.19 Follow Cost: 1.326978 s, Each: 2.629768 s, Runtime: 54 s.
    Process fans of 1253491601_1740148005 … Successful.

    No.20 Follow Cost: 2.308118 s, Each: 2.613685 s, Runtime: 56 s.
    Process fans of 1253491601_1798042953 … Successful.

    No.21 Follow Cost: 0.590607 s, Each: 2.517348 s, Runtime: 56 s.
    Process fans of 1253491601_1798050487 … Successful.

    No.22 Follow Cost: 3.258743 s, Each: 2.551048 s, Runtime: 60 s.
    Process fans of 1253491601_1786073203 … Successful.

    No.23 Follow Cost: 1.307878 s, Each: 2.496997 s, Runtime: 61 s.
    Process fans of 1253491601_1714431582 … Successful.

    No.24 Follow Cost: 0.882492 s, Each: 2.429726 s, Runtime: 62 s.

    关注一次花费时间太长了平均2s+ ,我换了多条线路试都差不多,难道是故意限制的,我写的程序关注到500就提示:M02016

  16. opsfans

    这是失败时花费的时间: 平均3.6秒左右

    No.807 Follow Cost: 0.367920 s, Each: 1.392454 s, Runtime: 1127 s.
    Process fans of 1253491601_1793233952 … Failed with [M02016]

    No.808 Follow Cost: 0.368783 s, Each: 1.391187 s, Runtime: 1128 s.
    Process fans of 1253491601_1739017832 … Failed with [M02016]

    No.809 Follow Cost: 0.367709 s, Each: 1.389921 s, Runtime: 1128 s.
    Process fans of 1253491601_1649489460 … Failed with [M02016]

    No.810 Follow Cost: 0.361609 s, Each: 1.388652 s, Runtime: 1129 s.
    Process fans of 1253491601_1780379624 … Failed with [M02016]

    No.811 Follow Cost: 0.366853 s, Each: 1.387392 s, Runtime: 1129 s.
    Process fans of 1253491601_1679468874 … Failed with [M02016]

    No.812 Follow Cost: 0.373574 s, Each: 1.386143 s, Runtime: 1129 s.
    Process fans of 1253491601_1797928635 … Failed with [M02016]

  17. opsfans

    我这里还记录了粉丝分页请求的时间:(我用的是机房线路)
    UID:1719481457,No.40,Cost:1.153667
    UID:1719481457,No.41,Cost:2.124952
    UID:1719481457,No.42,Cost:2.362792
    UID:1719481457,No.43,Cost:0.848301
    UID:1719481457,No.44,Cost:1.699721
    UID:1719481457,No.45,Cost:1.129684
    UID:1719481457,No.46,Cost:0.977071
    UID:1719481457,No.47,Cost:2.183946
    UID:1719481457,No.48,Cost:2.192847
    UID:1719481457,No.49,Cost:1.121598
    UID:1719481457,No.50,Cost:1.306889

  18. yangqing_fly

    杨老师,你好!
    你能谈谈sina微博是如何架构的吗?谢谢

  19. feicien

    我是一名大三学生,现在在做课程设计,一个微博网站,你可以向我提供新浪的微博的数据库表吗。

  20. 持续关注 持续学习中…

  21. 大型分布式应用一直是我所向往啊!

  22. zhangkun

    关注业界WEB技术的发展、变化、趋势信息,一般需要关注哪些网站、大会等信息源啊?

  23. sky

    深受高人笔下智慧的熏陶,现有一难题困惑,golang 是否比Erlang Scala更加优越,毕竟好多大牛支持这个新兴语言,不知您是否看好google的golang语言,提前谢谢您的回复了~~

  24. Tim

    各有各的好处。

  25. 在您Qcon上关于构建高性能微薄系统的PPT上,提到了新浪微薄长期招聘,遂用[email protected] 这个邮箱,向贵公司hr发了一封简历,希望您可以看到.

  26. 楼拴柱

    请问杨老师,Qcon会我也去了,请问,对于后台更新转播消息的队列优先等级这个是怎么分的?有一定规则没有,比如我转播了一条微薄,按照杨老师的说法,这条微博必定是关注我的一部分人的列表里先有我的转播信息,而另外一部分的则后续更新,是否是按照关注者的活跃度来分队列的优先度?活跃度什么算法定义?

  27. 你好TIM,想请教一下你网站的那个英语版本是添加文章的时候保存中英文两个版本还是通过翻译中文?

  28. roveratsh

    相比较Apc, Redis有什么优势,用Redis取代Apc的理由有什么

  29. shawn

    非常羡慕www的open环境!!!

  30. 非常喜欢大规模的分布式应用

1 2 3 4

Leave a Comment

Your email address will not be published. Required fields are marked *