利用magent搭建memcached集群
2016-07-17 01:48
393 查看
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.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
我们可以利用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.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
相关文章推荐
- Memcache的mutex设计模式 -- 高并发解决方案
- Nginx+Tomcat+Memcached集群Session共享
- windows环境下如何安装memcached教程
- php模块memcache和memcached区别分析
- Redis与Memcache区别
- CentOS6.3编译安装Memcached集群分布式缓存代理Magent-0.6出错汇总
- linux(centos7)的memcache
- Memcached集群/分布式/高可用 及 Magent缓存代理搭建过程 详解
- Memcached FAQ(2) 集群架构方面的问题
- 搭建 Windows Server 2003 + IIS6.0 + FastCGI + PHP5.3.29 + MySQL5.5.38 + Memcached1.2.6
- memcached预设值常量以及resultmessage翻译
- memcache set 和memcached get之间的一点差别
- Windows下memcached.exe的安装与配置
- 【原创】基于Memcached 实现用户登录的Demo(附源码)
- PHP如何将session保存到memcached中?如何分布式保存PHP session
- 开启memcache 扩展
- xampp3.2.1安装memcached扩展
- Caused by: java.lang.AbstractMethodError: de.javakaffee.web.msm.MemcachedBackupSessionManager.getCon
- Nginx+Tomcat+Memcached集群
- Mac OS 下搭建memcached java 增删改查