memcached 和它的代理

1.编译libevent  
./configure --prefix=xxx  
make && make install  


2.编译memcached  
./configure --prefix=xxx  
make && make install  


3.启动memcached  
服务器端的命令为：  
# /usr/local/bin/memcached -d -m 10 -u root -l 192.168.0.200 -p 12000 -c 256 -P /tmp/memcached.pid  



-d选项是启动一个守护进程，  
-m是分配给Memcache使用的内存数量，单位是MB，我这里是10MB，  
-u是运行Memcache的用户，我这里是root，  
-l是监听的服务器IP地址，若是有多个地址的话，我这里指定了服务器的IP地址192.168.0.200，  
-p是设置Memcache监听的端口，我这里设置了12000，最好是1024以上的端口，  
-c选项是最大运行的并发链接数，默认是1024，我这里设置了256，按照你服务器的负载量来设定，  
-P是设置保存Memcache的pid文件，我这里是保存在 /tmp/memcached.pid，  


想开机自动启动的话，只需在/etc/rc.d/rc.local中加入一行，上面命令  
有人用如下命令：  
/usr/local/memcached/bin/memcached -d -m 20 -p 11211 -u apache  
上面有些东西能够参考一下：即，ip不指定时，默认是本机，用户，最好选择是：apache 或 deamon  
这样，也就是属于哪一个用户的服务，由哪一个用户启动。  


4.memcached退出 
kill `cat /tmp/memcached.pid` 


5.安装libmemcached 
./configure --prefix=/xxxx/libmemcached --with-memcached=/xxxx/memcached/bin/memcached
make && make install 


--with-memcached 选项要指定到memcached可执行文件 
gcc是4.1，所以只能用老版本libmemcached(选了libmemcached-0.50) 


6.使用 
pythom-memcached下载连接不可用 ( http://www.tummy.com/software/python-memcached/) 
改用 
pylibmc (  https://pypi.python.org/pypi/pylibmc#downloads) 
  
7.安装magent


ketama.* 是一致性hash的实现


0.5版本： 
mkdir magent  
cd magent/  
wget http://memagent.googlecode.com/files/magent-0.5.tar.gz  
tar zxvf magent-0.5.tar.gz 


#这两步操做很奇怪，但颇有效  
/sbin/ldconfig  
sed -i "s#LIBS = -levent#LIBS = -levent -lm#g" Makefile 


make  
cp magent /usr/bin/magent  
cd ../ 



0.6版本： 
不须要额外操做，直接执行make便可


-------------
光用不理解说不过去，加点料(  http://code.google.com/p/memagent/wiki/HowMagentWorks )：
-------------
部署结构：
client---magent---{普通memcached集群, 备份memcached集群}


工做方式：
1.get操做，先到普通mem上读取；若是失败，再到备份mem上读取(即服务器失效会致使两次读，不过只是特殊状况下的处理，能够接受)
2.若是一次get多个key的值，会逐个执行1.中的步骤
3.delete,incr,decr,add,set,replace,prepend,append,cas，同时操做{普通mem,备份mem}

     * 写操做：先操做备份men，再操做普通mem
     * 不关联二者之间操做的成功/失败

4.client从magent上断开，不影响magent保持与集群server的连接
5.建议：client和magent部署在一块儿，client经过127.0.0.1访问magent时，效率会更高
-------------


8.配置转发 
在memcached的bin/目录 
./memcached -m 1 -u root -d -l 127.0.0.1 -p 11211 
./memcached -m 1 -u root -d -l 127.0.0.1 -p 11212  
./memcached -m 1 -u root -d -l 127.0.0.1 -p 11213  
magent -u root -n 51200 -l 127.0.0.1 -p 12000  -s 127.0.0.1:11211  -s 127.0.0.1:11212  -b 127.0.0.1:11213 


- 分别在112十一、112十二、11213端口启动3个Memcached进程，在12000端口开启magent代理程序；  
- 112十一、11212端口为主Memcached，11213端口为备份Memcached；  
- 链接上12000的magent，set key1和set key2，根据哈希算法，key1被写入11212和11213端口的Memcached，key2被写入11211和11213端口的Memcached；  
- 当112十一、11212端口的Memcached死掉，链接到12000端口的magent取数据，数据会从11213端口的Memcached取出；  
- 当112十一、11212端口的Memcached重启复活，链接到12000端口，magent会从11211或11212端口的Memcached取数据，因为这两台Memcached重启后无数据，所以magent取得的将是空值，尽管11213端口的Memcached还有数据（此问题尚待改进）。 


9.测试流程 
参照  http://blog.s135.com/post/393/  其中使用的是magent-0.5 


我尝试了0.5和最新的0.6，但里面提到的重启后的” 因为这两台Memcached重启后无数据，所以magent取得的将是空值，尽管11213端口的Memcached还有数据（此问题尚待改进）“，仍然存在 



10.题外话，缓存集群的造成历程 
缓存集群不是天生就有的，只有应用场景的发展才会引起对集群的须要。 

STEP1：无缓存--->STEP2：单机memcached--->STEP3：memcached集群+请求端分片--->STEP4：memcached集群+单台代理--->STEP5：memcached集群+代理集群--->再之后，就没有之后了 

1~3阶段都是很轻松的(不少业务能到3阶段已是规模不小，值得庆幸了)； 
4阶段后期就会遇到各类压力，要考虑memcached单台失效对后端(极可能是DB或其余持久化存储)突发压力的影响;magent的备份服务器是方法之一，但具体的备份方案须要琢磨，简单的2倍存储代价不小； 
5阶段要考虑集群+集群的失效，须要引入DNS/名字服务等更低层的网络措施；