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.5cd 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查看，因此使用此命令会将防火墙开启，虽然规则是清空的，但仍会记录连接跟踪表。
扫一扫
671
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
