利用magent搭建memcached集群
memcached虽然能够通过分布式缓存,实现其中memcached宕掉不会丢失全部缓存数据,但部分数据还是难逃一劫。
我们可以利用magent代理memcached实现主从备份来保证缓存数据完好无损,而且magent还可以作为从继续使用,但大体工作原理如下:
1.magent每次写数据都会写到主memcached和从memcached上,并且向主从memcached写的算法一样;
2.当主memcached宕掉,magent会向从memcached中读取数据;
3.当主memcached恢复后,magent将重新向主memcached中读数据;此时由于主memcached刚恢复,其中并无数据,因此会导致部分数据无法读取,这也是magent的一大缺点。
针对magent的缺点有几种想法:
1.在生产环境中主memcached宕掉的可能性非常小,大部分时间都是工作的;而从memcached只是在主memcached宕掉后才使用,因此从memcached分配的空间不可能和主memcached一样,这样无疑是在浪费宝贵的内存空间。
2.既然从memcached分配空间较小,而随着存入的数据会越来越多,会导致缓存的数据不断被过期驱逐出内存,因此在主memcached宕掉后,只能暂时起到缓解数据库压力的作用。
3.主memcached宕掉后,不宜直接将其启动,还是在数据库压力比较小的时候再启动吧,就当预热缓存。
总结:我引入magent除了主从方面,还考虑到magent---magent实现memcached入口的负载均衡,也就是说读写请求按照一定的算法分配到两个magent入口上,既能达到高可用,还能起到负载均衡。
一。安装部分
1.安装memcached-1.2.2
cd libevent-2.0.22-stable ./configure --prefix=/usr/local/libevent make make install cd memcached-1.2.2 ./configure --prefix=/usr/local/memcached --with-libevent=/usr/local/libevent make make install ###安装错误### memcached.c: 在函数'add_iov'中: memcached.c:696:30: 错误: 'IOV_MAX'未声明(在此函数内第一次使用) memcached.c:696:30: 附注: 每个未声明的标识符在其出现的函数内只报告一次 make[2]: *** [memcached-memcached.o] 错误 1 需要修改memcached.c文件: /* FreeBSD 4.x doesn't have IOV_MAX exposed. */ #ifndef IOV_MAX #if defined(__FreeBSD__) || defined(__APPLE__) # define IOV_MAX 1024 #endif #endif 改成: /* FreeBSD 4.x doesn't have IOV_MAX exposed. */ #ifndef IOV_MAX # define IOV_MAX 1024 #endif ###启动错误### [root@test memcached-1.2.2]# /usr/local/memcached/bin/memcached /usr/local/memcached/bin/memcached: error while loading shared libraries: libevent-2.0.so.5: cannot open shared object file: No such file or directory 需要修改: ln -s /usr/local/libevent/lib/libevent-2.0.so.5 /lib64/libevent-2.0.so.52.安装magent-0.5
cd magent-0.5 /sbin/ldconfig sed -i "s#LIBS = -levent#LIBS = -levent -lm#g" Makefile make 报错如下: gcc -Wall -O2 -g -c -o magent.o magent.c magent.c:65:19: 错误:event.h:没有那个文件或目录 magent.c:124: 错误:字段‘ev’的类型不完全 magent.c:154: 错误:字段‘ev’的类型不完全 magent.c: 在函数‘server_free’中: magent.c:468: 警告:隐式声明函数‘event_del’ magent.c: 在函数‘put_server_into_pool’中: magent.c:522: 错误:‘sizeof’不能用于不完全的类型‘struct event’ magent.c: 在函数‘out_string’中: magent.c:696: 错误:‘EV_WRITE’未声明(在此函数内第一次使用) magent.c:696: 错误:(即使在一个函数内多次出现,每个未声明的标识符在其 magent.c:696: 错误:所在的函数内也只报告一次。) magent.c:699: 警告:隐式声明函数‘event_set’ magent.c:699: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c:700: 警告:隐式声明函数‘event_add’ magent.c: 在函数‘do_transcation’中: magent.c:816: 错误:‘sizeof’不能用于不完全的类型‘struct event’ magent.c:818: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c:818: 错误:‘EV_WRITE’未声明(在此函数内第一次使用) magent.c: 在函数‘start_backup_transcation’中: magent.c:902: 错误:‘sizeof’不能用于不完全的类型‘struct event’ magent.c:904: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c:904: 错误:‘EV_WRITE’未声明(在此函数内第一次使用) magent.c: 在函数‘try_backup_server’中: magent.c:994: 错误:‘sizeof’不能用于不完全的类型‘struct event’ magent.c:996: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c:996: 错误:‘EV_WRITE’未声明(在此函数内第一次使用) magent.c: 在函数‘drive_memcached_server’中: magent.c:1014: 错误:‘EV_WRITE’未声明(在此函数内第一次使用) magent.c:1060: 错误:‘EV_READ’未声明(在此函数内第一次使用) magent.c:1062: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c: 在函数‘process_get_response’中: magent.c: 在函数‘process_get_response’中: magent.c:1236: 错误:‘EV_WRITE’未声明(在此函数内第一次使用) magent.c:1238: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c: 在函数‘process_update_response’中: magent.c:1283: 错误:‘EV_WRITE’未声明(在此函数内第一次使用) magent.c:1285: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c: 在函数‘drive_backup_server’中: magent.c:1305: 错误:‘EV_WRITE’未声明(在此函数内第一次使用) magent.c:1343: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c:1343: 错误:‘EV_READ’未声明(在此函数内第一次使用) magent.c: 在函数‘drive_client’中: magent.c:1618: 错误:‘EV_READ’未声明(在此函数内第一次使用) magent.c:1669: 错误:‘EV_WRITE’未声明(在此函数内第一次使用) magent.c:1682: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c: 在函数‘server_accept’中: magent.c:1734: 错误:‘sizeof’不能用于不完全的类型‘struct event’ magent.c:1735: 错误:‘EV_READ’未声明(在此函数内第一次使用) magent.c:1735: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c: 在函数‘main’中: magent.c:2106: 警告:隐式声明函数‘event_init’ magent.c:2111: 错误:‘EV_READ’未声明(在此函数内第一次使用) magent.c:2111: 错误:‘EV_PERSIST’未声明(在此函数内第一次使用) magent.c:2121: 警告:隐式声明函数‘event_loop’ make: *** [magent.o] 错误 1 修改Makefile LIBS = -levent -lm -L/usr/local/libevent/lib INCLUDE=-I/usr/local/libevent/include 再重新make,出现以下 gcc -Wall -O2 -g -I/usr/local/libevent/include -c -o magent.o magent.c magent.c: 在函数‘writev_list’中: magent.c:623: 错误:‘SSIZE_MAX’未声明(在此函数内第一次使用) magent.c:623: 错误:(即使在一个函数内多次出现,每个未声明的标识符在其 magent.c:623: 错误:所在的函数内也只报告一次。) make: *** [magent.o] 错误 1 需要修改vim ketama.h 在第一行加上 #ifndef SSIZE_MAX 在第四行加上 #define SSIZE_MAX 32676 在最后添加 #endif 再重新make,出现以下则成功 [root@test magent]# make gcc -Wall -O2 -g -I/usr/local/libevent/include -c -o magent.o magent.c gcc -Wall -O2 -g -I/usr/local/libevent/include -c -o ketama.o ketama.c gcc -Wall -O2 -g -o magent magent.o ketama.o -levent -lm -L/usr/local/libevent/lib 执行magent后又报错,则需要执行cp magent /usr/bin/magent bash: magent: command not found 执行magent出现以下则表示成功 [root@test magent]# magent please provide -s "ip:port" argument memcached agent v0.4 Build-Date: Apr 23 2015 21:24:28 Usage: -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 don't go to background -k use ketama key allocation algorithm -f file, unix socket path to listen on. default is off -i number, set max keep alive connections for one memcached server, default is 20 -v verbose二。部署
如上图所示:
1.magent1、magent2作为memcached的总入口,我们使用算法来实现负载均衡,分配读写请求,无论使用哪个入口分配到后端的memcached是一样的,因为它们分配memcached使用的都是同一个算法consistent-hash
2.后端mecached1,mecached2,mecached3,mecached4多位4个主memcached
3.magent3作为从,同时也是从memcached的入口,其后端还有两个memcached5,mecached6;由magent3,mecached5,mecached6共同组成从memcached
工作流程:
1.magent1,magent2接受写请求,将key分别写入mecached1-mecached4中,同时也将key写入从memcached上,也就是magent3上,magent3再分别写入mecached5,mecached6中;主和从都是用的同一个分配算法
2.magent1,magent2接受读请求,将分别向主memcached中进行读取,而不想从memcached中读取;
3.一旦mecached1-mecached4中有一个memcached宕掉,此时magent1和magent2将向从memcached,也就是magent3中读取数据,达到缓存数据不丢失的效果;
4.当主中的memcache恢复后,将再次加入主memcached中,此时magent1和magent2将不会向从memcached中读数据了,但是写仍正常进行;
启动如下:
memcached1-memcached6 /usr/local/memcached-1.4.22/bin/memcached -u root -d -p 11211 -m 1024 -c 102400 /usr/local/memcached-1.4.22/bin/memcached -u root -d -p 11212 -m 1024 -c 102400 /usr/local/memcached-1.4.22/bin/memcached -u root -d -p 11213 -m 1024 -c 102400 /usr/local/memcached-1.4.22/bin/memcached -u root -d -p 11214 -m 1024 -c 102400 /usr/local/memcached-1.4.22/bin/memcached -u root -d -p 11215 -m 1024 -c 102400 /usr/local/memcached-1.4.22/bin/memcached -u root -d -p 11216 -m 1024 -c 102400 magent3 /usr/bin/magent -u root -n 102400 -l 192.168.3.127 -p 12002 -s 192.168.3.127:11215 -s 192.168.3.127:11216 magent1: usr/bin/magent -u root -n 102400 -l 192.168.3.127 -p 12000 -s 192.168.3.127:11211 -s 192.168.3.127:11212 -s 192.168.3.128:11213 -s 192.168.3.127:11214 -b 192.168.3.127:12002 magent2: usr/bin/magent -u root -n 102400 -l 192.168.3.127 -p 12001 -s 192.168.3.127:11211 -s 192.168.3.127:11212 -s 192.168.3.128:11213 -s 192.168.3.127:11214 -b 192.168.3.127:12002
magent1,magent2算法:
1.可以根据magent总入口的个数(此处为2),使用除以2取余的方式,若为0分配到magent1,若为1分配到magent2,这样会实现将请求平均分配到magent1和magent2上
注:
1.若memcached读写的数据多,一定将关掉防火墙或将防火墙设置为不使用跟踪链接表,否则会导致/var/log/message报错“kernel: nf_conntrack: table full, dropping packet”,详情请参考本博客中的博文http://blog.csdn.net/yanggd1987/article/details/45886913。
2.使用service iptables stop关掉,并且不能用iptables -L -vnx查看,因此使用此命令会将防火墙开启,虽然规则是清空的,但仍会记录连接跟踪表。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。