周末的时候看到这篇 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--
Google的技术也很开放吧
我敢打赌，Google开放的技术绝对比Facebook要多得多
真巧啊，今天正好打算研究一下memcached，你就写一篇相关文章。google很多好的技术还是没有拿出来分享，这点的确不如facebook。我同意博主的观点。
淘宝和支付宝也不见得开放了什么技术
翻译了该文章：
http://shiningray.cn/scaling-memcached-at-facebook.html
觉得楼主的描述有点容易误导人，你这里第三段和Apache没有关系
@ShiningRay
我也没说和 Apache 有什么关系
更新了一下
我是来抓BUG的，那个延迟是173us（1 microseconds = 1 us = 1 微妙），不是ms。ms是毫秒（millisecond）。
如果是173ms那就慢死了。。。
@Joshua Zhu
多谢，订正了
刚刚翻译的第二版本的中文版: http://www.tagidea.com/show/146.html
Google开放了大量的技术和代码，我试着列举一些：
Protocol Buffer
GLog
GTest
GMock
TCMalloc
GUICE (Lightweight Dependency Injection framework for Java)
Gear
O3D for browser
OpenSocial's implementation: Shindig
...
这些很不少吧，呵呵：）