Facebook 的 Memcached 扩展经验

周末的时候看到这篇 Scaling memcached at Facebook,感觉挺有料。但似乎又没什么可写的。最多就是准翻译一下。

相比之前介绍过的数据( 5TB数据/400台服务器).,现在 Facebook 在 Memcached 上的内容已经超过 28TB,总服务器数量超过 800 台。可见硬件降价真是够快的,内存的确便宜得很。

Facebook 作出改进的第一个问题是 Apache (连接带来的)进程连接开销问题。实现了一个针对 TCP/UDP 的共享的进程连接缓冲池。共享的方式比针对单连接独占内存的方式节省不少内存资源。考虑到一共有 800 台乃至更多的服务器,总体节省的内存资源是惊人的。

第二个改进是 UDP 模式的效率问题。第三个改进是网络中断给 CPU 带来的影响,这个我觉得就是变相的实现了 Intel I/OAT 的某些功能。补充一句,网络中断的问题其实是给很多企图制造山寨存储的技术人员一个拦路虎。

最后一个问题是在 8 核芯片上发现的新瓶颈。这个问题我想对于在多核机器上跑 MySQL 也会有很大借鉴作用。CPU 不是越多越好。有些开源软件与硬件的配合上面应该的确稍微滞后(不是落后)一点。

四个大的改进的结果是从 50, 000 /s 的 UDP 请求到 300,000 /s 的 UDP 请求支撑能力,延迟只有 173 微秒。

Facebook 的技术还是挺开放的。这一点上比 Google 强多了。

EOF

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

10 thoughts on “Facebook 的 Memcached 扩展经验

  1. fire9

    真巧啊,今天正好打算研究一下memcached,你就写一篇相关文章。google很多好的技术还是没有拿出来分享,这点的确不如facebook。我同意博主的观点。

    Reply
  2. Joshua Zhu

    我是来抓BUG的,那个延迟是173us(1 microseconds = 1 us = 1 微妙),不是ms。ms是毫秒(millisecond)。
    如果是173ms那就慢死了。。。

    Reply
  3. Jacky

    Google开放了大量的技术和代码,我试着列举一些:
    Protocol Buffer
    GLog
    GTest
    GMock
    TCMalloc
    GUICE (Lightweight Dependency Injection framework for Java)
    Gear
    O3D for browser
    OpenSocial’s implementation: Shindig

    这些很不少吧,呵呵:)

    Reply

Leave a Reply

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