学步园

Flare, Green Lab开发的开源产品,底层使用TC, 完全兼容Memcached协议（ASCII，非binary)。主要有以下特性:

• 支持Master/slave复制
• 支持master 分区
• 支持动态节点添加删除，可以failover
• 持久存储

现在似乎大家都很关心好的key/value存储方案。作为传统数据库的补充。Memcached由于缺乏持久存储功能，因此无法作为一个可靠的key/value方案。

我之前关注过基于Memcached派生的一些方案，包括

memcachedb
- 新浪团队的,bdb+memcached协议

tokyo tyran
t - TC+memcached网络接口

LightCloud
在Tokyo Tyrant上实现了多节点的分布式管理。

repcached
－ 在memcached源码基础上增加复制功能

redist
- 除了string，还允许存储list、set等类型

除了上述软件，还有一些用Erlang,Java的方案,我并没有考虑。首先，我的使用场景还没有大到那个地步，我希望选择一个性价比更高的中低端方案
这其中，最关注的是TT(Toyko tyrant)。

但TT令我不太满意的是对于memcached的协议的兼容性并不够好，比如不能正确处理过期，也不能处理flag。导致客户端无法正常解压缩和

unserialize,虽然在client端都能处理，不过当时是打算作为一个session

storage,无法自动过期就比较麻烦，解决方案是通过在TT端执行lua可以进行gc处理，总体感觉不够完满。

memcachedb 对于存储定长字段不错，但不固定长度记录的存储似乎不够好，也没有现行的例子。

repcached 仅仅是支持mm复制，但无法正面解决持久存储的问题。

redist 当初测试时缺乏我需要的api。不过目前已经有了PHP PECL版本的api。 redist的复制机制现在也有了很大的改进。redist的应用实例不多。但是，我认为它和mongoDb一样，值得持续关注。

flare 则是最后选择的。经过测试，虽然速度上没有其他那么快，但其良好的扩展能力让我非常满意。此外，对于memcached协议的兼容性也做的很好。

还有1个特性，flare的key可以超过256bytes,而value可以超过1mb。 传统memcached由于内存分配策略因此有上述限制。

flare的底层存储是可以扩展的，目前使用的是tc(tokyo cabinet)。

从这个结构上看，倒是一个tt的很好替代品。

flare的运行性能还是不错，目前在GREE中得到实际应用，摘自项目网站描述：

Flare is running at GREE (one of the major SNS services in Japan) w/

6 masters and 6 slaves (over 2,000M keys), and 500-1,000 qps (load

average is nearly 0.00…).

看起来很诱人。因为同样TT超过100M的key，性能会直线下降。plurk的lightclound通过多节点的负载均衡解决了这个问题。（btw,plurk.com目前是被和谐中,要想取得lightclound源码还需要穿墙，唉)

以下是在我的osx上进行的安装测试。

1. 首先下载源码

http://labs.gree.jp/Top/OpenSource/Flare/Download-en.html

2. 使用port安装boost

$ port

install boost

3. 安装tc

http://tokyocabinet.sourceforge.net/

4. 编译flare

tar zxvf flare-1.0.8.tgz

./configure –with-boost=/opt/local –prefix=/opt/flare

make install

flare编译后只有2个文件

flarei,flared

分别是index server和node server.

很清爽啊。

5.运行

flare sources下有一个etc目录，中间分别有index server, node server的配置。

可以直接复制到/opt/flare/etc

然后使用

flared –daemonize -f

flarei –daemonize -f

就可以跑起来了。

6.概念

Flare有几个概念，需要理解

index server

这是索引服务器，用于控制node server的状态

注意，client并不直接和index server进行交互。

node server

这是实际存储节点. node有3种role:

master/slave/proxy

master是主节点,slave是分流节点，用于同步复制master

proxy则将client的请求转发到当前合适的节点(包括master/slave)。

有的人不太理解为什么要用proxy，是否多此一举，而实际测试表明，

通过proxy转发的请求的确要比直接connect到实际节点速度差很多。

这是因为，flare是一个集群，其中的node server是可以动态添加，删除的。

当某个node down后，index server会检测到，并标志其state为down。

此外，master 支持partition，因此通过proxy节点，client无需处理这些复杂问题。

根据作者的建议, proxy node应该和client本地运行，这样可以减少多余的tcp请求。

下面是我写的一个脚本，用于搭建一个典型的测试场景：

1个index server

2个master node,启用partition

1个slave，启用balance

由于flare把ip:port作为一个node，因此只需要1个ip，不同的port就可以快速实现测试需要的环境。

$./start_flare.sh

#启动index server,监听 127.0.0.1:12120

flarei –daemonize -f /opt/flare/etc/flarei.conf

#proxy

flared –daemonize –data-dir /opt/flare/var/data/d0 –index-server-name

127.0.0.1 –index-server-port 12120 –server-name 127.0.0.1 –server-port

12121

#master1 node

flared –daemonize –data-dir /opt/flare/var/data/d1 –index-server-name

127.0.0.1 –index-server-port 12120 –server-name 127.0.0.1 –server-port

12122

#slave node

#flared –daemonize –data-dir /opt/flare/var/data/d2 –index-server-name

127.0.0.1 –index-server-port 12120 –server-name 127.0.0.1 –server-port

12123

#master2

#flared –daemonize –data-dir /opt/flare/var/data/d3 –index-server-name

127.0.0.1 –index-server-port 12120 –server-name 127.0.0.1 –server-port

12124

echo “waiting dameon startup…”

sleep 3

echo “set nodes role….”

# 当某个node加入时,默认是proxy role，因此需要修改这些role

# 通过telnet到index server，可以执行这些命令,我们在脚本中可以使用

# nc来自动执行

# node role的命令格式：

# node role server port master|slave|proxy balance partiion

echo “node role 127.0.0.1 12122 master 1 0″|nc 127.0.0.1 12120

# 设置为slave, balance 为2,给于2倍read权重

echo “node role 127.0.0.1 12123 slave 2 0″|nc 127.0.0.1 12120

# 第2个master node,将partition设置为1，表明这是第2个partion，允许

＃将部分数据从原来的master 同步过来

echo “node role 127.0.0.1 12124 master 1 1″|nc 127.0.0.1 12120

sleep 2

echo “stats nodes”|nc 127.0.0.1 12120

STAT 127.0.0.1:12121:role proxy

STAT 127.0.0.1:12121:state down

STAT 127.0.0.1:12121:partition -1

STAT 127.0.0.1:12121:balance 0

STAT 127.0.0.1:12121:thread_type 16

STAT 127.0.0.1:12122:role master

STAT 127.0.0.1:12122:state down

STAT 127.0.0.1:12122:partition 0

STAT 127.0.0.1:12122:balance 1

STAT 127.0.0.1:12122:thread_type 17

STAT 127.0.0.1:12123:role slave

STAT 127.0.0.1:12123:state prepare

STAT 127.0.0.1:12123:partition 0

STAT 127.0.0.1:12123:balance 0

STAT 127.0.0.1:12123:thread_type 18

STAT 127.0.0.1:12124:role master

STAT 127.0.0.1:12124:state prepare

STAT 127.0.0.1:12124:partition 1

STAT 127.0.0.1:12124:balance 1

STAT 127.0.0.1:12124:thread_type 19

END

stats nodes可以列出当前各个节点的状态信息

注意, 有些节点的state是prepare，表明正在进行同步复制。

我进行了一个简单的测试, 分别读写1M 记录，

测试代码

?php



$host = $argv[1];



$port = $argv[2];



set_time_limit(0);



echo "connect to $host $port /n";



$memcached = new Memcached();



$memcached->addServer($host,$port);





$loop = 1000000;



echo "start set tests.../n";



$start =microtime(true);



for ($i=0; $i < $loop; $i++) {





$memcached->set(md5("k$i"),md5("k$i"));



}



$end = microtime(true);



echo "ok./n";



$total1 = $end-$start;



echo "start get tests.../n";



$start =microtime(true);



for ($i=0; $i < $loop; $i++) {





$memcached->get(md5("k$i"));



}



$end = microtime(true);



$total2 = $end-$start;



echo "ok./n";



echo "set time:$total1 ",$loop/$total1,' rps',"/n";



echo "get time:$total2 ",$loop/$total2, ' rps',"/n";



?>

当单节点执行set/get操作时，速度和memcached

的ascii模式基本一样，rps只略低几百个。

但是使用proxy 节点后，只有原来的一半。

============

推荐的Flare的适用场景:

1. 最正统的就是key/value storage。我自己将flare作为doggy中dhash的后端实现。

2. Session Storage。 比如PHP，可以直接适用memcached的session_handler。由于是持久的，因此解决原来memcached的尴尬和困扰。

3. 其他的基于key/value的扩展方案

Flare可以直接替代Memcached么？

答案是否。Flare的优势和本质是分布式key/value的持久存储，而不是作为一个cache。作为一个caching方案，要比memcached差很多。

尤其是启用了binary protocol后，memcached的优势很明显。