首页|五四陈后院|百丁屋论坛 CNFLEX组织|md5破解|关于|Profile
    • 802.1x代码 | bbsdown代码 | php手册 | 技术资料翻译
    收藏本页设为首页

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

    2009年12月02日 16:12五四陈科学院-php与java科学院我要评论(27)
    字号：T|T

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

    —-

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

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

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

    现在面临的挑战

    分发压力：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/uncategorized/net-new-to-live-for-all-to-share.html

    相关阅读：

    分类: linux, 其他, 架构   Tags: ,

    [五四陈科学院出品]

    返回顶部

    网友评论:

      27条评论

      • At 2009.12.02 16:17, Twitter Trackbacks for 人人网新鲜事分享现场直播 | 我是陈科学院-about php and java|php与java科学院 [54chen.com] on Topsy.com said:

        [...] First Tweet: 5 minutes ago 54chen Influential 54chen 人人网新鲜事架构分享现场直播进行中 http://www.54chen.com/844-net-new-to-live-for-all-to-share/ retweet [...]

        [Reply]
        • At 2009.12.02 16:28, Tim said:

          强烈期待架构图

          [Reply]
          • At 2009.12.02 16:35, arbow said:

            围观等待图片出炉

            [Reply]
            • At 2009.12.02 16:45, Tim said:

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

              [Reply]
              • At 2009.12.02 16:48, cc0cc said:

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

                [Reply]
              • At 2009.12.02 16:55, Tim said:

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

                [Reply]
                • At 2009.12.02 17:05, Tim said:

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

                  [Reply]
                  • At 2009.12.02 17:12, Tim said:

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

                    [Reply]
                    • At 2009.12.02 17:21, Lo said:

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

                      [Reply]
                      • At 2009.12.03 13:45, cc0cc said:

                        兄弟这个结论相当准确

                        [Reply]
                      • At 2009.12.02 23:20, deng said:

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

                        [Reply]
                        • At 2009.12.03 13:44, cc0cc said:

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

                          [Reply]
                        • At 2009.12.06 09:09, 一周废话汇总【54chen Twitter 2009-12-06】 | 我是陈科学院-about php and java|php与java科学院 said:

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

                          [Reply]
                          • At 2009.12.21 22:32, xnang said:

                            “索引信息feed id list存在TC”具体是怎么存贮的？索引的数据结构？没搞明白，谢谢

                            [Reply]
                            • At 2009.12.22 21:16, cc0cc said:

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

                              [Reply]
                            • At 2009.12.23 17:40, xnang said:

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

                              [Reply]
                              • At 2009.12.25 21:26, cc0cc said:

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

                                [Reply]
                                • At 2009.12.26 00:06, skey said:

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

                                  [Reply]
                                  • At 2009.12.26 00:09, cc0cc said:

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

                                    [Reply]
                                    • At 2009.12.26 00:20, skey said:

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

                                      [Reply]
                                      • At 2009.12.26 19:32, cc0cc said:

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

                            • At 2009.12.27 01:52, blue said:

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

                              [Reply]
                              • At 2009.12.28 17:28, cc0cc said:

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

                                [Reply]
                              • At 2010.01.17 22:33, test said:

                                TC保存索引采用hash模式？

                                [Reply]
                              • At 2010.01.18 15:59, Roast said:

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

                                [Reply]
                                • At 2010.01.18 19:42, cc0cc said:

                                  的确是这样的 所以用SSD

                                  [Reply]
                                (Required)
                                (Required, will not be published)

                              推广信息