上周挤到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官方的开发人员们情何以堪？
所谓LiteCloud，无非就是前些天提到的LightCloud的php版本实现。这个和原来的python版本有一些区别，会造成不兼容，如下：
把Consistent Hashing算法换成了ketama，在pecl的memcached扩展里有简单方法可以实现，效率比单纯的php好很多，能快个10倍吧。没有重复造轮子，因此我很是得意。
LightCloud是最近看到的一个比较轻巧的分布式key-value数据库，尽管这类软件已经让人觉得审美疲劳，但我仍然觉得它的设计思路值得一提。
特色
除开其项目主页上列出来的特点不提，我觉得还能数得上的特色有：
继上次解决memcache连接慢问题以来，好长一段时间没在这个问题上翻过跟头。这一次我又在生产环境观察到php和memcache的连接时间经常会在50ms以上。
作为一个cache，占用了这么长的执行时间，天理何在？
实际的运行环境如下：
在php开发中，开启memcache的数据压缩存储是一件很简单的事情。在多数情况下，压缩数据不仅不会降低程序的执行效率，反倒会因为网络传输的开销降低，带来速度提升。看看最常用的Memcache::set方法:
bool Memcache::set ( string $key , mixed $var [, int $flag [, int $expire ]] )
在这个方法中，将$flag设置为MEMCACHE_COMPRESSED即可启用memcache压缩存储。
这样做有什么弊端？
twitter最近将ruby实现的消息队列服务器starling开源了，这是一个支持memcache协议的轻量级持久化服务器，因此使用php/perl/ruby/java等多种客户端都没问题，可以将较慢的处理逻辑通过消息队列放在后台处理，同时也支持多点分布式处理。周末找了个闲置的centos 5机器搭了一套starling试用，配合php的memcache扩展测试一番，有点意思。
starling安装步骤
centos默认不带ruby，得重新装，以下安装步骤都是以root身份跑的。
最近用xdebug观察线上程序的运行时间统计，发现往日里跑起来像飞的memcache居然是系统中拖后腿的耗时大户，连接时间特长。
运行环境
webserver是apache + php
memcached 1.3将开始支持Binary Protocol，下面是一篇介绍的ppt。
大概看了一遍，可以认为memcache的binary协议相对原来基于文本的协议，略快一些。key的长度可以到65536(2 bytes)。而memcache 1.3将仍然保持向后兼容，同时支持文本协议和binary协议。
在邮件组里看到这个补丁，能够将memcache中所有的key dump出来。
I have just finished a patch to dump all keys from memcached.
And I am glad to share this patch to anyone who wants to use it.
In the attachment, there are two python scripts which are used for dump all keys from a memcached server,