原文地址：
http://ultrasql.blog.51cto.com/9591438/1636374Memcached集群介绍由于Memcached服务器与服务器之间没有任何通讯，并且不进行任何数据复制备份，所以当任何服务器节点出现故障时，会出现单点故障，如果需要实现HA，则需要通过另外的方式来解决。通过Magent缓存代理，防止单点现象，缓存代理也可以做备份，通过客户端连接到缓存代理服务器，缓存代理服务器连接缓存连接服务器，缓存代理服务器可以连接多台Memcached机器可以将每台Memcached机器进行数据同步。如果其中一台缓存服务器down机，系统依然可以继续工作，如果其中一台Memcached机器down掉，数据不会丢失并且可以保证数据的完整性。搭建Memcached集群Magent的架构方案已经在上一篇博文
《Magent介绍》中有详细描述。现以如下图示例架构方案说明Magent如何搭建Memcached集群，而在生产环境需要根据自身业务特点设计健壮的架构方案。
现有测试机：192.168.11.51/52/68先在三台测试机上安装好libevent和memcached，启动memcached实例；然后在51和52上安装好magent，启动magent实例。安装和启动memcached实例详细步骤，请参见之前的博文
《Memcached 1.4.22安装和配置》，分别启动如下实例：
安装和启动magent实例笔者在测试magent-0.6.tar.gz时，该版本在与最新版memcached运行下不够稳定，如下配置以magent-0.5.tar.gz为示例。1. 安装magent到/usr/local下：
2. 修改配置：在ketama.h文件开头添加
将
修改为：
保存3. 编译：
输出如下信息：
4. 查看命令帮助：
5. 启动magent实例
测试流程登录51上的magent，存储key1到key5：
登录到51上的memcached，获取到了key2和key4：
登录到52上的memcached，获取到了key1、key3和key5：
登录到68上的memcached，获取到了key1到key5:
停掉52的memcached进程，通过51上的magent获取到了key1到key5：
恢复52的memcached进程，通过51上的magent，只获取到了key2和key4：
通过以上测试可以得出结论：1. 通过magent的连接池存放的值会分别存在magent代理的所有memcached上去。2. 如果有一个memcached宕机通过magent代理方式还能取到值。3. 如果memcached修复重启后通过magent代理方式取到的值就会为Null，这是由于memcache重启后里边的值随着memcache服务的停止就消失了（因为在内存中），但是magent是通过key进行哈希计算分配到某台机器上的，memcache重启后会还从这台机器上取值，所有取到的值就为空。解决办法：1. 在每次memcache宕机修复后可以写一个程序把集群中的其他memcache的所有信息全给拷贝到当前宕机修复后的memcache中。2. 自己写代理，当从一个memcached服务上取到的值为Null时再去其他memcached上取值。注意事项：magent的调用方式同memcached一样，客户端可以不用改代码即可实现切换到magent模式下。缓存与DB的同步比较保险的做法是：查询的时候从缓存中取，add、updae、delete的时候同时操作缓存与DB。当然你也可以定时同步缓存与DB的数据，不同的业务应该有不同的选择。magent-0.6版本相关的错误汇总产生如下错误：
解决方法：在ketama.h文件开头添加
再次make产生如下错误：
解决方法：
找到LIBS = /usr/lib64/libevent.a /usr/lib64/libm.a按照如下格式修改：LIBS = /usr/<libevent的安装路径>/libevent.a /usr/lib64/libm.a如：LIBS = /usr/lib/libevent.a /usr/lib64/libm.a保存再次make产生如下错误：
解决方法：
将
修改为：
保存再次make输出为：
