特色

除开其项目主页上列出来的特点不提，我觉得还能数得上的特色有：

1. 理论上可以用任意key-value数据库做为底层存储，现在支持以tokyo tyrant或者redis作为底层的存储，如果使用redis可以获得更好的性能（大概提升30%~50%）
2. 没有定制服务器端，基本上靠客户端语言来实现键值查找。优点是部署起来比较简单，缺点也是显而易见的，效率会有损失。
3. 可以很方便的移植到其它语言上，我已经在github上找到一个ruby版本，甚至还有个php版本的实现。
4. 可以方便的增加节点。
5. 结构简单，方便hack

LightCloud的设计原理

Hash ring

LightCloud不能免俗的使用了一致性hash算法（Consistent Hashing），这是为了避免新增数据节点时发生集体拆迁事件。Consistent Hashing算法的原理请参考这里。

last.fm的工作人员写的ketama算法算是比较常见的一致性算法，在libmemcached里大量使用。而LightCloud的作者当时还没发现合适的ketama python版，所以干脆自己捋起袖子写了个python版本的hash_ring，不到50行。这个是量身定制的，所以效率也还过得去，但是兼容ketama就别想了。

献上hash圈圈一个以明志：

LightCloud的hash环有什么与众不同？

其它分布式key-value数据库采用的办法是复制数据到多个节点上，例如Amazon Dynamo的复制策略图：

Dynamo用了许多办法解决consistent问题，系统相当复杂。而LightCloud直接使用tokyo tyrant的master-master复制功能，大幅简化了这部分的逻辑。所以在它的hash环上，单个节点其实是一对master-master的tokyo tyrant，焦不离孟不离焦。

在新增数据节点时，如果没有路由服务找到正确的服务器，可能会损失数据。那么LightCloud继续采用流氓手段解决这个问题，他又给上了个环，保证不会发生意外。这两个hash环里的节点仍然是之前提到的tokyo tyrant双人组，一个环叫lookup，记录了每一个key保存在哪个storage节点上；另外一个环叫storage，这是真正存放数据的地方。于是它的结构图变成了下面这个样子：

这部分比较难以理解，试着就上图阐述一下：

1. 一个名叫A的家伙，住在storage_SB地区(storage ring)。同时，我们还告诉记性好的lookup_B(lookup ring)，A君的地址为storage_SB。
2. 很不幸或很幸运，咱们的数据膨胀到需要扩容了，于是新增了一个违章建筑storge_X，这个该死的建筑正好影响了我们找到A君。这时候，我们还可以问起记性好的lookup_B，A君住在哪个角落里啊？ —— lookup_B日道：他就住在sotrage_SB一带~
3. lookup这群家伙记性虽然好，但是也架不住人多，再也记不住这么多人的住址，所以又新来了几个记性好的lookup。这个会影响咱们找到storage住哪吗？答案是不会，因为没有新增别的违章storage建筑，咱们不需要问路也能找着人。

按照以上推论，一定要避免出现同时增加lookup和storage节点，这很可能会损失数据。

参考网页

• http://opensource.plurk.com/LightCloud/

简单的nginx配置示例

/etc/nginx/conf.d/ooso.conf:

把hiphop-php编译后的代码跑在4247端口，然后通过nginx把所有对php的请求转发到这个端口，看上去就像我们平常配置的php fastcgi，不是吗？

这样做有什么好处

• 支持负载均衡
• 支持ssl
• 支持gzip压缩
• 用nginx来挡住DoS攻击
• 因为我们的代码需要经过编译才能上线，代码多起来这个时间还真不短，不能像之前单纯的php那样爽快覆盖就完事。把经过编译的最新代码部署在别的端口上，用nginx快速切换，应该是一个比较实际的用法。

额外的技巧

看wiki学到的额外技巧。以下配置段可以防止某些人把别的垃圾域名指向你的主机，结果被搜索引擎认为你用多个域名搞了一堆重复的内容建设，降低搜索权重。

Centos用户的好消息

Update: 在centos 64位机上完全通过rpm安装hiphop-php的步骤也已经提供了。

在邮件组上看到有人提供了centos下安装hiphop相关的rpm列表，把这些rpm装好，再按照wiki上专心编译hiphop即可。也许再过一阵，就会有人直接提供hiphop的rpm包，那就彻底方便了。

rpm列表

• libicu42-4.2.1-1.x86_64.rpm
• libicu-devel-4.2.1-1.x86_64.rpm
• icu-debuginfo-4.2.1-1.x86_64.rpm
• icu-4.2.1-1.x86_64.rpm
• libcurl4-devel-7.20.0-1.x86_64.rpm
• libcurl4-7.20.0-1.x86_64.rpm
• curl-debuginfo-7.20.0-1.x86_64.rpm
• curl-7.20.0-1.x86_64.rpm
• libevent-1.4.13-1.x86_64.rpm
• boost-devel-1_37_0-1.x86_64.rpm
• boost-debuginfo-1_37_0-1.x86_64.rpm
• boost-1_37_0-1.x86_64.rpm
• cmake-2.6.4-7.el5.x86_64.rpm

Ubuntu 9.10用户的安装指南

Building and Installing on Ubuntu 9.10

看起来还是ubuntu用户最清爽。

注：如果使用了32bit的ubuntu，请使用patch过的hiphop-php进行编译。

Fedora用户的编译步骤

Building HipHop PHP for Fedora 12 on 64 bit and 32 bit Systems

BTW: 目前hiphop-php仅支持64位操作系统。

我的机器环境是

• Centos 5.3 x86_64
• 8G内存
• Intel(R) Xeon(R) CPU E5420 @ 2.50GHz

安装注意事项

编译的时候碰到的问题很多，但是基本上都是按照wiki上的步骤进行的。我觉得比较重要的几点：

• wiki上的Required Packages包包列表都要检查一遍，比如版本号，是否安装过，像binutils-dev这种就很容易忽略
• 版本符合的话，直接用yum安装这些包就可以了
• wiki上有类似Boost 1.37 is the minimum version字样，说明开发者可能就是在这个版本下开发的，我试了下最新版本的boost，编译到后来反而出错
• 如果yum上没有符合版本的lib库，可以手动编译，但是编译时建议就放在自己的home下，比如：
  ./configure --prefix=/home/user
• tbb Intel’s Thread Building Blocks这个包有些麻烦，记得按照wiki上说的步骤安装

测试hiphop-php

安装完成之后，时间也不是太多，所以我仅仅是简单的测试了一个php文件，代码如下：

用hphp进行编译:

提示生成新的可执行文件

做一下运行时间对比：

没看出来编译成c++代码之后有太大的性能提升，估计是俺的使用手法问题？在邮件组里观察几天再说。

Update

facebook将优化之后的编译参数提交到了github，于是我重新编译并测试一遍这段相同的代码：

可以看到，经hiphop编译后的php，执行时间几乎快了一倍。

git-review为git新增了一个很方便的代码review途径，利用这个命令，可以调用别的工具比如vimdiff来review代码的改动。下面简单记录一下使用的过程：

下载并安装

首先确认已经装好了git，剩下的事情比较简单。

这几步为git新增了一个review命令。

git-review的使用

查看指定版本的改动

出现提示

Now processing modified file foo.php
foo.php [diff]>

由于我配置了diff工具为vimdiff，所以接下来就可以用vimdiff查看foo.php在58e2fb834793f5c6c1fdd900a1c0224a44735962这个版本与最新版本之间有什么不同。

查看两个版本之间的改动

在review每个代码之前，都可以使用help查看git review命令的帮助，如果放弃review，那么直接敲退出就可以了。

• 安装卸载，升级rpm软件包只需一条命令即可
• 统一部署，便于维护
• 比手工编译的方式要快

于是我需要把日常使用到的一些php扩展做成rpm包，但是手工写spec文件比较繁琐，因此pear的这个小工具PEAR_Command_Packaging帮了不少忙。它会给pear工具新增一个选项：
pear make-rpm-spec [options]

这个命令行将会创建一个rpm的.spec文件，包含指定pear包的定义，而且也适用于pecl的php扩展。

创建pear rpm包的例子

$ cd /path/to/rpm-build-tree/SPECS
$ pear make-rpm-spec ../SOURCES/Net_Socket-1.0.tgz
Wrote RPM spec file PEAR::Net_Socket-1.0.spec
$ rpm -bb PEAR::Net_Socket-1.0.spec
...
Wrote: /path/to/rpm-build-tree/RPMS/noarch/PEAR::Net_Socket-1.0-1.noarch.rpm


关于make-rpm-spec的帮助

pear help make-rpm-spec

作为一个cache，占用了这么长的执行时间，天理何在？

实际的运行环境如下：

• apache + mod_php
• php-memcache扩展版本为2.2.5
• memcache的并发连接数在400左右，相当少

这次memcache扩展用的是最新的稳定版，无可挑剔。所以刚开始我认为是网络环境的问题，于是直接采用telnet工具直连memcache进行测试，发现速度飞快！一点便秘感都没有！所以把目光仍然放回到memcache扩展上来，集中对比较慢的addServer方法各项参数进行排查。

Memcache::addServer方法

bool Memcache::addServer ( string $host [, int $port = 11211 [, bool $persistent [, int $weight [, int $timeout [, int $retry_interval [, bool $status [, callback $failure_callback [, int $timeoutms ]]]]]]]] )

比对结果表明，$weight参数对memcache的连接时间有显著的影响，$weight的默认值为1，一旦设置为别的数值，连接时间便会由毫秒级变成50ms左右，立竿见影。

鉴于php-memcache扩展一贯恶劣的表现，俺不得不痛下决心迁移到新的memcached扩展上。memcached扩展基于libmemcached开发，而且提供了丰富的接口方法，应该是更好的选择。

goo.gl shortener plugin使用方法

• 你必须是firefox用户，安装了vimperator插件
• 下载goo.gl shortener插件，并放置在vimperator的plugin目录下，对于windows用户来说，通常应该在 x:\Documents and Settings\YourName\vimperator\plugin目录下。如果你是linux用户，那么你应该知道吧？
• 在vimperator输入框里输入 :shorten就能够获得当前url的短链接，并复制到剪贴板

话说那个客官，要觉得这工具好使，在转载的时候千万留下原地址，谢谢您了。

• 支持Semisynchronous Replication，这个是从早期google的semi-sync patch转过来的，能够做到master-slave的半同步复制
• 集成Innodb plugin 1.0.6
• 新的partition语法

这个版本还不适合用在正式环境。想想以后也许可以用mysql mmm + mysql 5.5提供可用性更好的服务，前提是它已经足够稳定，或者是percona版本？

• apache + php
• 使用smarty模板输出内容
• 页面最终输出内容较大，80k+
• 页面执行时间在500ms以上

祭出法宝xhprof对问题页面做了细致检查，发现页面的瓶颈竟然是模板（编译后的）中的一个echo语句，这个echo语句输出的字符串比较大，大概是50k+字节，花费时间为400多毫秒，占整个页面执行时间的80%。这样的echo输出在站点首页中其实是很常见的事情，没有数据库操作，按道理执行时间不应该这么长。

于是猛力使用搜索技能，最终在php手册的echo部分找到了一些蛛丝马迹，早在2003年就有前辈认为通过echo输出大字符串到客户端会引起服务器的性能问题，据我测试，在这个场景下使用print其实也是一样的慢。建议的解决办法是把字符串切割成更小的字符串输出，展现速度会有提升，输出函数如下：

但是上面的处方不太对症，整个echobig的输出时间仍然在400毫秒左右，没有太大改善。

考虑到是输出大量内容到客户端比较慢，于是检查了apache的配置，原来还没打开deflate进行压缩，遂启用之。再次使用xhprof进行检查，这条echo的输出时间降低到5ms左右。

400ms到5ms，一个配置问题会产生80倍的差距，还真是省老钱了。这个故事告诉我们，压缩输出真的很重要。

当时还想着能不能hack一下git-svn脚本，其实后来看看文档，clone操作可以使用参数-r$REVNUMBER:HEAD检出指定版本后的代码，因此，更好的步骤应该是这样：

• svn info http://your-svn, 并记录最后的版本号，假设是260
• 假设要检出最后10个版本，做个简单的减法： 260 - 10 = 250
• 开始clone操作了
  git svn clone -r250:HEAD --prefix=svn/ http://your-svn

按这个办法，clone的时间的确是减少了许多。

• 如果用来分区的字段和主键不是同一个，则不能分区
• 见很早前的一篇译文mysql 5.1新功能 －－ 按日期分区，如果查询条件中没有正确利用到分区的字段，那么partition的效果为零
• mysql 5.1.31之前的partition功能有较大的bug，会导致自增字段不能正常自增，怎么个不正常法？auto_increment值会非正常增长，突然比当前的最大id小很多，插入数据时导致duplicate key错误。

这些问题都能凑合着对付过去，但是partition功能和auto_increment似乎是天生的敌人。从使用习惯上来说，我们会把auto_increment字段设置为主键，这个字段要是unique的才比较稳妥，这个情况下如果希望用其它字段来进行分区的话，几乎就成了不可能的任务。以这张表为例：

这个时候试图以uid进行分区会怎么样？是以怎样的惨淡结局收场？变通的办法是对自增字段做一些调整，从mysql的手册来看，自增字段不一定要设置成主键，仅仅是普通的index也可以，那么把表结构换成下面这个样子，就可以分区成功。

我在实际环境中有一张表达到了几亿条数据，如果要用时下流行的sharding策略，必须在代码上做一些改动，当时偷了点懒直接使用partition功能，用了大半年倒也相安无事。只是分区表占用内存相当的大，如果有其它的表经常出现慢查询耗费服务器资源，那么雪崩效应就出现了，所有的查询都会堵塞变得非常慢。

• 这工具用python写的
• 用svn保存配置文件，用subcon比较容易的部署到多台服务器上
• 既然是用svn保存，那么回滚到指定版本也是支持的
• SystemImager工具的集成是做为添头附送的，理论上你可以利用这个工具做到一步安装服务器

初印象就是如此，实际的使用时，你首先要在svn上创建两个目录

• base
• roles

然后可以试着提交一些服务器配置文件例如/etc/hosts到base下,再通过简单命令把配置同步到服务器上
subcon -n

也可以指定别的类型的配置文件例如www或者memcache，以服务器apache配置文件/etc/httpd为例：

• 创建目录roles/www
• 提交/etc/httpd目录到roles/www目录下
• 十来个字符就可以部署这些文件到服务器上
  PLAIN TEXT
  CODE:

  1. subcon -n -owww

同样的道理，只要在roles路径下新增各种类型的配置文件，就能比较快捷的部署到服务器上。还有些小功能，需要使用中自己挖掘了:

• 更改某个配置文件之后，自动执行指定的命令行，参看/etc/subcon.conf
• 回滚配置文件到指定版本的功能，这功能一般是在悲剧发生时才会使用吧？所以这个功能也很悲剧的有bug，手工hack一下才能使用。提示：在代码中找到revision字样，用int转换一下类型，命令行参数到了python里面估计都算string了。
• 如果有多个服务器共用部分配置文件，可以利用svn:externals属性创建一个链接
• subcon实际上是python的svn客户端 + rsync

工具很简单，也有些bug,但是足够用了。

这个脚本做了两件事情：

1. 左侧新增了一个 check now 按钮
2. 右边新增了一个检查频率

声明，这个脚本只针对firefox用户。

使用方法：

1. 安装greasemonkey插件
2. 安装我改写过的邮件检查脚本

我也不是这工具的原创，改写了一些而已，原版的在这里

如果你不幸安装了上一个版本的脚本，那么记得卸载掉

Update: 原来的脚本已不可用，请移步使用另外一个更新脚本.

• 安装greasemonkey插件
• 安装猴子脚本
• 安装我改写过的邮件检查脚本

这个工具的用途是在页面上方的“刷新”旁边新增一个链接“刷新POP3邮件”，点击之后会马上检查所有的POP3邮箱。至于自动刷新功能，还等着看官你自己搞定呢。

BTW:如果是英文版的gmail，请手工修改gmail_pop3_quick_checker.user.js，我都提取出来了。

而xhprof就显得很轻量，是否记录profile可以由程序控制，因此，用在生产环境中也就成为一种可能。在它的文档上可以看到这样一种用法：

以万分之一的几率启用xhprof，平时悄悄的不打枪。

在程序结尾处调用方法保存profile

也可以用register_shutdown_function方法指定在程序结束时保存xhprof信息，这样就免去了结尾处判断，给个改写的不完整例子：

至于日志，我暂时用的是最土的文件形式保存，定期清除即可。

BTW:xhprof生成的图形方式profile真是酷毙了，哪段代码成为瓶颈，一目了然。

在这个方法中，将$flag设置为MEMCACHE_COMPRESSED即可启用memcache压缩存储。

这样做有什么弊端？

如果没有做额外判断，每一次写入memcache都会启用压缩，不管数据的大小。对应的，每次获得数据都需要做一次解压缩的操作，这是典型的一刀切手法。实际上在数据很小的情况下，不需要压缩，在这个基础上压缩省不了多少空间。

更好的压缩策略？

好了，我的想法是在数据超过一定大小（比如2k）的情况下，才开启压缩。这个好办，捋起袖子就干，在调用Memcache::set方法之前，首先判断一下数据的大小，一个strlen就搞定了，再简单不过了。

有人可能会问了，array和object怎么办，这玩意可不能用strlen判断长度。

这还真能难住我一阵子，要知道把array/object写入memcache的时候，php会自动做serialize，再把它当作字符串插入memcache。

谁会采用这段代码？看起来非常山寨，而且serialize也不快，赔本买卖。

更好的办法！

上面的文字都是废话，直接看这段就好。Memcache::setCompressThreshold方法可以包办之前所有的逻辑。

Memcache::setCompressThreshold — Enable automatic compression of large values

bool Memcache::setCompressThreshold ( int $threshold [, float $min_savings ] )

举个例子，下面这段会自动启用压缩策略，当数据大于2k时，以0.2的压缩比进行zlib。

根据我的测试结果，setCompressThreshold方法会忽略Memcache::set的flag参数。

目前在windows下，最好的git客户端恐怕就是装一个cygwin。鼓捣了一个时辰，整理好一些可用的配置文件，陈列一下以备下次使用：

~/.bash_profile

偶尔还会使用svn验证一下check in的情况，刚转过来不放心啊，下面的配置是为了防止svn命令行乱码。命令行git-svn在/usr/sbin/git-core/路径下，是一个perl脚本，为了方便，我把这个路径加入了PATH环境变量。

~/.inputrc

去掉注释即可

~/.gitconfig

常用操作

读写分离脚本的问题

刚启动mysql proxy的时候，经常报错 -- "Mysql server has gone away"。我进一步缩小了可能出问题的范围(把环境简化是很重要的查错手段哦！)，比如只连接一个mysql，或者只连接本机的mysql，没有太大帮助，最后是在mysql proxy的日志文件中看到些蛛丝马迹：

(critical) proxy-plugin.c:1367: (connect_server) [string "/usr/local/share/mysql-proxy/r..."]:69: .address is deprecated. Use .src.name or .dst.name instead
(critical) (read_query) [string "/usr/local/share/mysql-proxy/r..."]:179: .address is deprecated. Use .src.name or .dst.name instead
(critical) proxy-plugin.c.1115: I have no server backend, closing connection

在mysql proxy的论坛上看到有人碰到类似的问题，很简单，读写分离的lua脚本还是旧的，0.6.1时代的产物了，更糟糕的是，即便是即将发布的0.7.0，rw-splitting.lua也是旧版本的。lua脚本中的.address需要替换成.src.name或者.dst.name。

解决办法 —— 下载更新之后的rw-splitting.lua，情况会好转。

使用prepare方法无法获得结果

我在测试代码中采用php的pdo_mysql，单独连接mysql是毫无问题的，然而配合mysql proxy使用则是屡屡受挫，查询经常没有结果返回，比较随机，从日志中也找不到有帮助的内容。这次没有找到解决办法，所以我绕了过去，在连接mysql的时候使用伪prepare的方式：

据称emulate方式的性能比prepare要好，所以这也算安慰奖了。

专门的lua脚本分支

lua脚本开发滞后，是一个比较严重的问题，所以在邮件组上看到有个新的lua脚本分支出来 —— https://launchpad.net/mysql-proxy-lua-scripts。希望开发速度能跟上来。

keepalive参数

mysql proxy还不算太稳定，偶尔crash我也不觉得惊讶，所以新增的keepalive参数很有用。在proxy启动的时候，加上--keepalive参数，它便会努力保持proxy的运行状态，停止了也会自动重启。

什么情况？

原来的url

http://www.xxx.com/demo/oldpage.php?param1=1&param2=2

转换后的url

http://www.xxx.com/newpage.php?url=%2Fdemo%2Fmypage.php%3Fparam1%3D1&param2%3D2

需要把粗体部分的url进行urlencode，能看出上面的字符"?&="都分别转义过，作为参数发给另外一个url。那么这时候请出rewrite还真是最合适不过了。

坎坷的Rewrite经历

查查rewrite手册，俺这才知道，转义这活，非得派出RewriteMap的map function才能做的比较漂亮。现在只有四个内部map function可供差遣：

• toupper: Converts the key to all upper case.
• tolower: Converts the key to all lower case.
• escape: Translates special characters in the key to hex-encodings.
• unescape: Translates hex-encodings in the key back to special characters.

那么很快就有了第一个rewrite出现：

RewriteMap escape int:escape
RewriteRule ^/([^/]*)$ /newpage.php?mi_url_suffix=${escape:$1?%{QUERY_STRING}} [L,PT]


注：这里的int不是intger的意思，它是internal的缩写，表示调用内部函数。

看上去非常简单，跑起来貌似也正....常？且慢，俺打开RewriteLog一瞅，形式不容乐观啊，"&"字符通通没有转义。看来是失败了，爬到狗狗上翻了一下，貌似escape对"?="之类的特殊字符是不做转义的，晕。

RewriteMap到底

接着细看apache的rewrite手册，发现RewriteMap还支持自定义脚本，那么还得使出俺的看家绝技——php了。首先弄一个能转义的php，必须非常简单，复杂了apache容易挂掉，写出来发现想复杂都挺难啊：

/usr/local/bin/escape.php

在这个脚本里可别使用php:://stdin之类的，具体原因查php手册。相应的，rewrite规则如下：

RewriteMap escape prg:/usr/local/bin/escape.php
RewriteRule ^/([^/]*)$ /newpage.php?mi_url_suffix=${escape:$1?%{QUERY_STRING}} [L,PT]


rewrite规则没有太大的改变，prg表示使用自定义脚本。现在这个版本总算正常运作了。

本次1.2相对第一个版本的改动

• 将javascript提取出来放到单独的js文件里，这是为了减小每个url的大小，浏览器也会对外部js进行缓存，有效的减少带宽输出
• js文件已经用yui compressor压缩过，只有900多个字节
• 支持多语种搜索，修改文件中的$related_posts_lang变量即可，中文用户需要将这个值修改为zh-CN(默认是en-US)
• 可以去除网页标题中的站名以及部分连接字符，让标题更简短且有意义

下载search engine related posts 1.2

http://wordpress.org/extend/plugins/search-engine-related-posts/

starling安装步骤

centos默认不带ruby，得重新装，以下安装步骤都是以root身份跑的。

yum install ruby ruby-devel rubygems
gem install memcache-client starling


如果你使用yum找不到ruby的相关包，请记得添加epel repository。安装之后新增的程序：

• /usr/bin/starling #一个ruby脚本，starling的服务程序
• /usr/bin/starling_top #starling的状态检查程序，可以查看starling的运行状态，类似memcache的状态显示，不同的是能够显示每个key的状态

starling启动后默认会在22122端口蹲点守候。

为了使用方便，我修改了一个starling在centos下的启动脚本，放在/etc/init.d/starling，下载地址：http://customcode.googlecode.com/files/starling。使用方法：
/etc/init.d/starling start|stop|restart

测试程序

以下是在测试中用的php脚本，说实话php在循环比较大的时候没啥优势，但是关键是简单，几行就搞定了。

写入的测试程序

读出来的测试程序

性能测试

测试条件:

• key的长度16B
• value的长度100B,
• 8个并发写入进程
• 每个进程插入10,000条记录

平均每个进程花了7秒完成写入操作，那么照这样计算：

10000 * 8 / 7 = 每秒写入11428次

以上测试进行的比较随意，而且我懒得插入大量数据来测试了，这个比较花时间，所以测试结果仅供参考。由于starling是目前twitter在生产环境中运行的，经过实践检验过，稳定性应该不成问题。

首先让EPEL (Extra Packages for Enterprise Linux) repository 生效
# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm

确定这些包已经安装：GNU Autotools, flex, pkg-config, bazaar, MySQL client libraries
# yum install autoconf automake libtool flex pkgconfig bzr mysql-devel

centos下自带的libevent版本超老，这个没有别的办法，只能自己重新编译，版本需要在1.4.0以上，越高越好

$ wget http://monkey.org/~provos/libevent-1.4.9-stable.tar.gz
$ tar zvfx libevent-1.4.9-stable.tar.gz
$ cd libevent-1.4.9-stable
$ ./configure
$ make
# make install


centos自带的glib版本也比较老，mysql proxy 0.7.0以上需要glib2 2.16.0以上才能编译成功，因此不得不重新编译glib

$ wget http://ftp.gnome.org/pub/gnome/sources/glib/2.18/glib-2.18.4.tar.gz
$ tar zvfx glib-2.18.4.tar.gz
$ cd glib-2.18.4
$ ./configure
$ make
# make install


编译安装lua 5.1

$ wget http://www.lua.org/ftp/lua-5.1.4.tar.gz
$ tar zvfx lua-5.1.4.tar.gz
$ cd lua-5.1.4
$ vi src/Makefile

在CFLAGS里加上-fPIC，因为我在64位机上编译出现了“relocations”错误


$ make linux
# make install
# cp etc/lua.pc /usr/local/lib/pkgconfig/


重要：让pkg-config找到自己编译的库在哪里

$ export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig


最后，从bazaar中检出最新的mysql-proxy源文件进行编译：

$ bzr branch lp:mysql-proxy
$ cd mysql-proxy
$ ./autogen.sh
$ ./configure
$ make
# make install


编译完成，可以检查一下最终结果：

# mysql-proxy -V



mysql-proxy 0.7.0
glib2: 2.18.4
libevent: 1.4.9-stable
admin: 0.7.0
proxy: 0.7.0


配置启动脚本，在系统启动时运行mysql-proxy

cd /etc/init.d
wget http://customcode.googlecode.com/files/mysql-proxy
chmod 0755 /etc/init.d/mysql-proxy
chkconfig mysql-proxy on


增加运行参数

cat >/etc/sysconfig/mysql-proxy



# Options to mysql-proxy
# do not remove --daemon
PROXY_OPTIONS="--daemon"


CTRL+D保存，然后就可以使用以下命令启动|停止mysql-proxy

/etc/init.d/mysql-proxy start|stop


参考文档：
How to Compile and Install MySQL Proxy from Bazaar on CentOS 5.2

里头有36个程序可供投票，基本上全是脚本语言大杂烩：php,perl,ruby,javascript。实现的应用也是五花八门，有相册，类twitter，小游戏，甚至还有php代码框架？摘录如下：

这段代码利用了php5.3的一些新特性：

• __DIR__
• Anonymous functions
• ?:运算符

代码只有131个字符，由于代码极为简陋，安全性也是没得保障的，只能算一个程序的统一入口罢了。

如果用php 5.2来写这段代码，大概就是：

如果要让这段代码变得实用点，可以在$c前面加上一个前缀，这样安全性会有进一步提升，代码也会相应的增加若干字节。

运行环境

• webserver是apache + php
• php memcache extension版本是3.0.2，当时是最新的beta版...
• 有4个memcache server可供使用
• 代码中会利用php的Memcache::addServer依次连接四个memcache，长连接方式

现象

完成四次addServer一共需要300ms以上，但是一旦连接上，获取单个item飞快，时间在3ms以下。
更可恶的问题在于，虽然执行了四次Memcache::addServer，但是实际使用的始终是最后一个memcache，这实在让人崩溃。

问题解决

使用了一点搜索技巧，在pecl.php.net上找到了类似的bug: First get slow when using multiple memcached servers

这个bug的描述如下：

We are monitoring memcached performance and noticed that when we added a second memcached via Memcache::addServer the first get request is always slower than the subsequent ones although we are using persitent memcached connections. Switching from crc32 to fnv hashing didn't help either. Is that delay explainable

看起来是最新的memcache extension有一些问题，尝试将这个扩展降级成最新的稳定版2.2.6，然后重启apache看看，memcache连接过慢的问题果然已经解决。

结论

吃螃蟹果然是要付出代价的。。