坚信科学,分享技术

2018全新版本,未来在blog.54chen.com更新博客!

>>>尝试更加利于阅读的2014版科学院,以后都在新版上写。

[科学院手记]人人网新鲜事分享现场转播

讲座已经开始,现在是人人网牛人张洁介绍。

----

现在是新鲜事后台架构牛人铁安在讲解新鲜事要完成的功能:

将一个用户产生的内容实时发送给与他相关的一群人。

尽可能地帮助用户保存内容。

现在面临的挑战

分发压力:5000W*100 全天分发的总量在五十亿左右。每秒分发的次数是六万次每秒。

现在有1.3t的内存占用。

----

老版本的新鲜事结构

----

新的系统结构

分发之后,内容本体丢进cache和db,dispatch服务通知到相关的人,分发后来的结构保存一人一条到TC

---

MENU

技术细节部分

分发部分的策略优化:瞬间分发海量数据,光良首页的例子(一百万的粉丝同时产生)。产品策略优化。

内存压缩技术:新鲜事内存结构(FlyWeight),字符串压缩存储(QuickLZ)

新鲜事存储方案

----

内存压缩技术:flyweight的设计思想

只要对象存在,所有的指针都能找到正确的内容。

boost::flyweight在高并发情况下有效率问题,自己实现了相同的功能。

各种压缩办法的性能比较:

QuickLZ的压缩比不是最高的,但解压缩是最快的;代码简单;支持追加方式的压缩;有成熟的商业应用。

boost::multi_index介绍 用来做多视图显示的东东 提供三种不同的索引方式

一段例子代码 c++代码。。。略鸟

-------

新鲜事存储方案

TC+Direct IO + SSD

key-value DB的一个表。

研究的三个开源项目:

Hypertable

tokyo tyrant

MemcacheDB (哈哈,测试了两个张宴兄弟的东东,感叹一下下,张宴兄弟在nginx和tt的文档贡献真是不浅)

TC的测试结果

读取很少的数据的情况下读和写都很快,在几个G之内的数据文件,数据量增加到一定程度写入会持续下降。100G一秒只能写入六七百次。所以单纯使用TC是不现实的。

新的方案

所有的写合并;通过LOG保证Down机后数据恢复;使用TC保存索引;使用异步IO读写文件;使用DirectIO屏蔽OS的Cache策略;使用SSD解决大量的并发读取。

SSD随机读和顺序读速度接近。五六万每次的速度。

-------

全场结束,答疑

-------


原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]
本文链接: http://www.54chen.com/life/net-new-to-live-for-all-to-share.html

This entry was posted in linux, 架构研究, 生活备份 and tagged , . Bookmark the permalink.

29 Responses to “[科学院手记]人人网新鲜事分享现场转播”

  1. Tim 说:

    强烈期待架构图

  2. arbow 说:

    围观等待图片出炉

  3. Tim 说:

    我觉得可以用LZO压缩算法,LZO的优势是即使压缩比高,解压不受影响的快,QuickLZ高压缩率下解压慢
    feed的特性也是一次生成,多次消费。

  4. cc0cc 说:

    据这位牛人的原话,压缩越高解压越快,还有append的支持是一个很关键的问题

  5. Tim 说:

    “100G一秒只能写入六七百次”
    不知道把TC在同一台机100G拆分成10个10G的进程会怎样

  6. Tim 说:

    SSD存取的数据和Memcached里面的数据是怎样分工的,cache的结构介绍下就好了

  7. Tim 说:

    我也总结下,看是否正确。
    人人网新鲜事使用的是一个feed“推”的架构,难点在分发后的存储上。
    解决方法是用QuickLZ压缩内容,feed内容用文件方式异步写入,索引信息feed id list存在TC,用SSD提高读写速度

  8. Lo 说:

    能不能推个动态对象的引用过去,这样对分发后的存储有没有帮助?

  9. deng 说:

    不如你们的瞬时推送数百万的信息是如何实现的?
    有无对用户是否活跃进行区分呢?

  10. cc0cc 说:

    并没有区分 注意在文中有1.4T的内存

  11. cc0cc 说:

    兄弟这个结论相当准确

  12. xnang 说:

    "索引信息feed id list存在TC"具体是怎么存贮的?索引的数据结构?没搞明白,谢谢

  13. cc0cc 说:

    只是保存了索引在tc 然后通过索引寻找内容

  14. xnang 说:

    你们的瞬时推送一条信息到几百万的用户怎么实现的呢?谢谢

  15. cc0cc 说:

    其实说得简单一点,1.5T的内存完成了这件事情。其实没有什么神秘的技术。

  16. skey 说:

    一个用户几百万好友的关系是存在内存数据库中?或者是缓存中?

  17. cc0cc 说:

    应该二者都有,具体的使用的地方不一样,近期我们的海量key-value系统也要出来了,用来存这个也不错

  18. skey 说:

    恩,期待你的经验啊,呵呵!另外在新鲜事中所有的写合并能给解释一下么?谢谢

  19. cc0cc 说:

    写合并应该是一个从内存到硬盘的批量刷新的过程,所以这个过程可能会有部分数据还在log文件里后掉电了。

  20. blue 说:

    你好:能详细的说一下feed是怎样分发的么?是根据每个人的好友关系循环的分发还是通过别的方法?谢谢!

  21. cc0cc 说:

    你好
    人人网新鲜事使用的是一个feed“推”的架构,难点在分发后的存储上。
    解决方法是用QuickLZ压缩内容,feed内容用文件方式异步写入,索引信息feed id list存在TC,用SSD提高读写速度
    TIM总结的很正确,建议你读读上下文

  22. test 说:

    TC保存索引采用hash模式?

  23. Roast 说:

    感觉IO可能会是个大问题。

  24. cc0cc 说:

    的确是这样的 所以用SSD

  25. leesum 说:

    人人网的open id构思很具有战略性。

  26. 54chen 说:

    open id不是原创啦 :)

Leave a Reply