Ubuntu 16.04通过Magent搭建Memcached集群（转）

一、下载Magent

官网：https://code.google.com/archive/p/memagent/downloads

离线版本：（链接: https://pan.baidu.com/s/1kU9DLI3 密码: k6qg）

二、编译安装

说明：magent由于是10年的产品，所以编译时一定会报错，但是先不要按照网上的修改来操作，应该先执行make，然后看错误来解决，因为每个系统的解决方式都不同，应该按照不同的系统来处理才是最优的解法。

前提：先安装Memcached，参考：http://www.cnblogs.com/EasonJim/p/7572264.html

解压：

mkdir magent    
tar -zxvf magent-0.6.tar.gz -C magent
sudo mv magent /usr/local
cd /usr/local/magent

编译：

1、在ketama.h文件开头添加

#ifndef SSIZE_MAX    
#define SSIZE_MAX 32767    
#endif

2、修改Makefile文件

ARCH := $(shell uname -m)
X64 = x86_64
CC = gcc
PROGS =    magent
ifeq ($(ARCH), $(X64))
    M64 = -m64
    LIBS = /usr/local/lib/libevent.a /usr/lib/x86_64-linux-gnu/libm.so
else
    LIBS = -levent -lm -L/usr/local/lib
endif

CFLAGS = -Wall -g -O2 -I/usr/local/include $(M64)

all: $(PROGS)

STPROG = magent.o ketama.o

ketama.o: ketama.c ketama.h
    $(CC) $(CFLAGS) -c -o $@ ketama.c

magent.o: magent.c ketama.h
    $(CC) $(CFLAGS) -c -o $@ magent.c

magent: $(STPROG)
    $(CC) $(CFLAGS) -o $@ $^ $(LIBS)

clean:
    rm -f *.o *~ $(PROGS)

说明：标红部分修改即可。

3、make编译成功

三、部署方案及说明

当网站访问量达到一定时，如何做Memcached集群，又如何高可用，是接下来要讨论的问题。

有这么一段文字来描述“Memcached集群”

Memcached如何处理容错的？

不处理！:) 在memcached节点失效的情况下，集群没有必要做任何容错处理。如果发生了节点失效，应对的措施完全取决于用户。节点失效时，下面列出几种方案供您选择：

* 忽略它！在失效节点被恢复或替换之前，还有很多其他节点可以应对节点失效带来的影响。

* 把失效的节点从节点列表中移除。做这个操作千万要小心！在默认情况下（余数式哈希算法），客户端添加或移除节点，会导致所有的缓存数据不可用！因为哈希参照的节点列表变化了，大部分key会因为哈希值的改变而被映射到（与原来）不同的节点上。

* 启动热备节点，接管失效节点所占用的IP。这样可以防止哈希紊乱（hashing chaos）。

根据上面的说法，Memcached其中一个节点失效以后，Memcached本身是没有任何策略维持失效转发的，这对于大型系统是一个无法接受的事实。

举例说明：

在客户端连接的部分写入多个服务器端的ip地址，客户端将会自动的把缓存数据分布的放在每个不同的机器上，如图所示：

缺陷说明：

如果其中一个缓存节点的机器down机，那么客户端存入的缓存数据将会丢失一部分，就是图中红色字体描述的“Losed 33% Cache Data”，也就是说那部分数据彻底没有了！如果是用户的关键性信息那么就玩大了，如图所示：

解决方案：采用缓存代理服务器

采用Magent缓存代理，防止单点现象，缓存代理也可以做备份，通过客户端连接到缓存代理服务器，缓存代理服务器连接缓存服务器，缓存代理服务器可以连接多台Memcached机器，如下图所示，配件清单如下：

Magent代理服务器：2台，分别为 192.168.1.2:12000、192.168.1.3:12000

Memcached主服务器：3台，分别为 192.168.1.4:11211、192.168.1.5:11211、192.168.1.6:11211

Memcached备服务器：2台，分别为 192.168.1.5:11211、192.168.1.6:11211

搭建Memcahced服务器：

在 192.168.1.4、192.168.1.5、192.168.1.6、192.168.1.7、192.168.1.8 上分别编译安装并运行Memcached

搭建Magent代理服务器：

在 192.168.1.2、192.168.1.3上分别编译安装magent

magent命令详解（使用Google来翻译）：

-h this message
-u uid
-g gid
-p port, default is 11211. (0 to disable tcp support)
-s ip:port, set memcached server ip and port
-b ip:port, set backup memcached server ip and port
-l ip, local bind ip address, default is 0.0.0.0
-n number, set max connections, default is 4096
-D do not go to background
-k use ketama key allocation algorithm
-f file, unix socket path to listen on. default is off
-i number, max keep alive connections for one memcached server, default is 20
-v verbose

在 192.168.1.2、192.168.1.3 上分别运行magent：

magent -u root -n 51200 -l 192.168.1.2 -p 12000 -s 192.168.1.4:11211 -s 192.168.1.5:11211 -s 192.168.1.6:11211 -b 192.168.1.7:11211 -b 192.168.1.8:11211

说明：常用两项-s为主节点，-b为备用节点。

测试缓存数据的分布情况说明：

1、Java连接magent，把缓存key1交给magent，magent根据自身的配置参数，再加上一定的哈希算法，会计算出key1存在3台主Memcached服务器的某一台上，然后以同样的算法，将key1也在2台备用的Memcached服务器中的某一台上，再存一份数据。即，主服务器是分布式存储的，同时，从服务器也是分布式存储的；

2、在Java获取缓存数据key1时，magent一旦得知数据所存的那台主Memcached服务器挂掉了，它就会转向从备用的Memcached服务器中获取数据。注意：服务器的定位选择算法跟存的时候是一样的。

3、有个缺陷，当down掉的那台主Memcached服务器重新恢复正常后，Memcahed里是没有数据的，即数据全部丢失，但此时备用的Memcached服务器又不会将数据同步到主服务器。

4、通过Memcached管理软件MemAdmin（点击下载）去查看上述数据分布情况，如下：

192.168.1.4 存有 snsgou6，snsgou3
192.168.1.5 存有 snsgou4，snsgou1
192.168.1.6 存有 snsgou5，snsgou2
192.168.1.7 存有 snsgou5，snsgou3，snsgou1
192.168.1.8 存有 snsgou4，snsgou6，snsgou2

5、Java连接代理的时候，最好每次随机性只连一台，这样，一旦某台代理挂了（即连不上），可切换连另外一台代理服务器。而随机性地去连，又保证了一定的负载均衡。

四、测试实例：

#启动magent实例   
/usr/local/magent/magent -u root -n 4096 -l 192.168.11.51 -p 11200 -s 192.168.11.51:11211 -s 192.168.11.52:11211 -b 192.168.11.68:11211    
/usr/local/magent/magent -u root -n 4096 -l 192.168.11.52 -p 11200 -s 192.168.11.51:11211 -s 192.168.11.52:11211 -b 192.168.11.68:11211

1、登录51上的magent，存储key1到key5：

telnet 192.168.11.51 11200
Trying 192.168.11.51...
Connected to 192.168.11.51.
Escape character is '^]'.
stats
memcached agent v0.4
matrix 1 -> 192.168.11.51:11211, pool size 0
matrix 2 -> 192.168.11.52:11211, pool size 0
END
set key1 0 0 1
1
STORED
set key2 0 0 2
22
STORED
set key3 0 0 3
333
STORED
set key4 0 0 4
4444
STORED
set key5 0 0 5
55555
STORED
quit
Connection closed by foreign host.

登录到51上的Memcached，获取到了key2和key4：

telnet 192.168.11.51 11211
Trying 192.168.11.51...
Connected to 192.168.11.51.
Escape character is '^]'.
get key1
END
get key2
VALUE key2 0 2
22
END
get key3
END
get key4
VALUE key4 0 4
4444
END
get key5
END
quit
Connection closed by foreign host.

登录到52上的Memcached，获取到了key1、key3和key5：

telnet 192.168.11.52 11211
Trying 192.168.11.52...
Connected to 192.168.11.52.
Escape character is '^]'.
get key1
VALUE key1 0 1
1
END
get key2
END
get key3
VALUE key3 0 3
333
END
get key4
END
get key5
VALUE key5 0 5
55555
END
quit
Connection closed by foreign host.

登录到68上的Memcached，获取到了key1到key5：

telnet 192.168.11.68 11211
Trying 192.168.11.68...
Connected to 192.168.11.68.
Escape character is '^]'.
get key1
VALUE key1 0 1
1
END
get key2
VALUE key2 0 2
22
END
get key3
VALUE key3 0 3
333
END
get key4
VALUE key4 0 4
4444
END
get key5
VALUE key5 0 5
55555
END
quit
Connection closed by foreign host.

停掉52的Memcached进程，通过51上的magent获取到了key1到key5：

kill `cat /var/run/memcached/memcached.pid`

telnet 192.168.11.51 11200
Trying 192.168.11.51...
Connected to 192.168.11.51.
Escape character is '^]'.
get key1
VALUE key1 0 1
1
END
get key2
VALUE key2 0 2
22
END
get key3
VALUE key3 0 3
333
END
get key4
VALUE key4 0 4
4444
END
get key5
VALUE key5 0 5
55555
END
quit
Connection closed by foreign host.

恢复52的Memcached进程，通过51上的magent，只获取到了key2和key4：

telnet 192.168.11.51 11200
Trying 192.168.11.51...
Connected to 192.168.11.51.
Escape character is '^]'.
get key1
END
get key2
VALUE key2 0 2
22
END
get key3
END
get key4
VALUE key4 0 4
4444
END
get key5
END
quit
Connection closed by foreign host.

通过以上测试可以得出结论：

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的数据，不同的业务应该有不同的选择。

参考：

http://kb.cnblogs.com/page/69074/

http://carvin.iteye.com/blog/825070

http://ultrasql.blog.51cto.com/9591438/1636374/（解决在Ubuntu编译Magent的问题）