关于“facebook的memcached实战”小记
上周挤到QCon的会场里，听了两场 —— Facebook的Memcached实战，以及Twitter 的可伸缩性数据架构。当时对facebook超大规模使用memcached印象很深刻，只可惜到现在也没见到这个的ppt。平时用php比较多，因此听闻同样使着php的facebook讲memcached，有些小小的感触，记录下来。
更高效的序列化函数
php有两个memcache扩展，默认都是使用php自带的序列化函数serialize来存储数组或对象。但是serialize最为人诟病的就是速度慢，序列化之后占用空间大。由于facebook已经在memcached里保存了200T字节的数据，因此序列化函数即便作出的百分之一的优化对它来说都是个不小的收益。他们发粪涂墙在thrift的binary协议基础上搞出了一个fb_serialize，据称这个序列化方法能快上3倍，快倒算了，还能节省30%空间， 200T字节的数据能节省出30%，简直就是传说中的银弹啊，这让php官方的开发人员们情何以堪？
facebook目前已经开源了thrift，其中自带了一个thrift协议的php扩展，但是这些代码里没有找到传说中的fb_serialize，我倒是从最近他们放出来hiphop-php里找到了这部分代码，哪位大侠去扒拉扒拉弄出来做成php扩展造福广大群众？
作为备选方案，我推荐igbinary，这也是一个binary的序列化方法。在上次的测试结果中，它甚至能节约50%的存储空间，速度也是稳超php原生的序列化方法，搞不好facebook换了这个序列化方法能省下更多的内存来？
节约每个item的存储空间有什么好处？我个人认为一个是省钱，另外一个就是能够带来速度上的提升。我们平常碰到稍大一点的item都得用gzip压的妥妥贴贴的才送到memcached里，网络传输的开销小了，这是实实在在的性能提升。何乐而不为？
mcproxy
mcproxy = memcached + proxy。facebook的机房遍布各洲，利用mcproxy来进行跨机房的同步或分发，全球制霸，指着太阳就能等到那天了。一般的互联网企业还真用不上这玩意，规模还没上去的时候，这些乱七八糟的只会拖后腿。facebook还没开源mcproxy，但是我找到两个替代品：
从项目描述来看，moxi最接近facebook介绍的mcproxy，成熟度也比较高。
数据的一致性
Marc Kwiatkowski在会场上用大篇幅的ppt和大量的动画来阐述这个问题，他们用了很多额外的手段来解决在跨机房情况下因为延时问题造成的脏数据。这一段看着挺晕，但是我们联想到facebook用到的多级cache技术: 本地全局变量 + apc + memcache，不难理解这样做颇有些道理，这相当于用memcache实现了一个版本控制系统。
我还是很晕这段ppt。
作者: Volcano 发表于April 30, 2010 at 12:38 am
onemonkey 于 2010-04-30 @ 18:07:13 留言 ：
我当天也是云里雾里的，这哥们在投影仪不停地出问题后，显然乱了阵脚，讲的飞快，很多内容没跟上，
Volcano 于 2010-04-30 @ 18:56:13 留言 ：
同感，京仪的讲台布局烂，设备更烂。
Dy Jersey 于 2010-05-20 @ 01:40:11 留言 ：
我当天也是云里雾里的，这哥们在投影仪不停地出问题后，显然乱了阵脚，讲的飞快，很多内容没跟上，
+1
jimmy 于 2010-09-09 @ 20:42:38 留言 ：
本地全局变量 + apc + memcache， 想请某大哥给诠释下，这里说到的 “本地区全局变量” 是怎么个究竟，恩。谢等了