Memcached集群/分布式/高可用 及 Magent缓存代理搭建过程 详解

当网站访问量达到一定时,如何做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 ,

参考:CentOS6.3编译安装Memcached

搭建Magent代理服务器

在 192.168.1.2、192.168.1.3 上分别 编译安装 magent [CSDN下载 Magent]

#编译安装安装magent到 /usr/local/ 下

cd /usr/local/
mkdir ./magent
cd ./magent
wget -c http://memagent.googlecode.com/files/magent-0.6.tar.gz
tar xzvf ./magent-0.6.tar.gz
/sbin/ldconfig
sed -i "s#LIBS = -levent#LIBS = -levent -lm#g" Makefile
make
cp ./magent /usr/bin/magent

注意:编译的过程中遇到了好几处错误,错误解决过程,请参考

CentOS6.3编译安装Memcached集群分布式缓存代理Magent-0.6出错汇总

magent命令详解:

-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

测试缓存数据的分布情况:

以前,我们用PHP连接多台Memcached服务器,做分布式缓存时,参考代码如下:

$memcache = new Memcache;
$memcache->addServer(‘localhost‘, 11211);
$memcache->addServer(‘localhost‘, 11212);
$memcache->addServer(‘localhost‘, 11213);
for ($i = 0; $i < 1000; $i++)
{
	$memcache->set($i, $i, 0, 1000);
}

现在,代码还是那段代码,只不过连接的主机不是Memcached服务器了,而是 Magent代理服务器,给 addServer()方法传参时,传入的是Magent主机IP与端口!测试代码如下:

$mem = new \Memcache();

$host = ‘192.168.1.2‘;
$port = ‘12000 ‘;
$mem->connect($host, $port);

$key1 = ‘snsgou1‘;
$value1 = ‘1‘;
$mem->add($key1, $value1);

$key2 = ‘snsgou2‘;
$value2 = ‘2‘;
$mem->add($key2, $value2);

$key3 = ‘snsgou3‘;
$value3 = ‘3‘;
$mem->add($key3, $value3);

$key4 = ‘snsgou4‘;
$value4 = ‘4‘;
$mem->add($key4, $value4);

$key5 = ‘snsgou5‘;
$value5 = ‘5‘;
$mem->add($key5, $value5);

$key6 = ‘snsgou6‘;
$value6 = ‘6‘;
$mem->add($key6, $value6);

说明:

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

2、在PHP获取缓存数据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、PHP连接代理的时候,最好每次随机性只连一台,这样,一旦某台代理挂了(即连不上),可切换连另外一台代理服务器。而随机性地去连,又保证了一定的负载均衡。

6、本来我打算通过修改配置文件php.ini,使PHP系统的会话(Session)通过Magent代理保存到Memcached服务器中,修改方式参考:PHP如何将session保存到memcached中?如何分布式保存PHP session

但是呢,把Mangent代理服务器IP及端口贴到php.ini后(已重启了相关服务器),发现会话根本没保存到Memcached中,即PHP底层不识别Magent代理,郁闷!!!

参考:

http://www.javabloger.com/article/memcached-cluster-error-msag.html

magent编译安装及常见错误

magent做memcached集群

[张宴]Memcached的代理服务器软件:magent使用小记[原创]

magent 配置问题详解

时间: 2024-11-05 14:48:40

Memcached集群/分布式/高可用 及 Magent缓存代理搭建过程 详解的相关文章

Memcached 集群的高可用(HA)架构

Memcache自身并没有实现集群功能,如果想用Memcahce实现集群需要借助第三方软件或者自己设计编程实现,这里将采用memagent代理实现,memagent又名magent,大家注意下,不要将这二者当成两种工具.至于memcache.magent的安装请参考文章  在Linux上安装Memcached服务和 magent编译安装及常见错误 整体架构 直接上图: 从图中可以看到有两个magent节点,两个memcached节点,每个magent节点又分别代理两个memcached节点,应用

java架构师大型分布式综合项目实战,高并发,集群,高可用,程序设计,性能优化,架构设计,负载均衡,大数据量

* { font-family: "Microsoft YaHei" !important } h1 { color: #FF0 } 15套java架构师.集群.高可用.高可扩 展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布 式项目实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Redis.ActiveMQ.Nginx.Mycat

浅谈web应用的负载均衡、集群、高可用(HA)解决方案(转)

1.熟悉几个组件 1.1.apache     —— 它是Apache软件基金会的一个开放源代码的跨平台的网页服务器,属于老牌的web服务器了,支持基于Ip或者域名的虚拟主机,支持代理服务器,支持安 全Socket层(SSL)等等,目前互联网主要使用它做静态资源服务器,也可以做代理服务器转发请求(如:图片链等),结合tomcat等 servlet容器处理jsp.1.2.ngnix     —— 俄罗斯人开发的一个高性能的 HTTP和反向代理服务器.由于Nginx 超越 Apache 的高性能和稳

15套java架构师、集群、高可用、高可扩 展、高性能、高并发、性能优化大型分布 式项目实战视频教程

2017-08-09 * { font-family: "Microsoft YaHei" !important } h1 { color: #FF0 } 15套java架构师.集群.高可用.高可扩 展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布 式项目实战视频教程 视频课程包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Redis.ActiveMQ.

java架构师、集群、高可用、高可扩展、高性能、高并发、性能优化

15套java架构师.集群.高可用.高可扩展.高性能.高并发.性能优化.Spring boot.Redis.ActiveMQ.Nginx.Mycat.Netty.Jvm大型分布式项目实战视频教程 视频课程内容包含: 高级Java架构师包含:Spring boot.Spring  cloud.Dubbo.Redis.ActiveMQ.Nginx.Mycat.Spring.MongoDB.ZeroMQ.Git.Nosql.Jvm.Mecached.Netty.Nio.Mina.性能调优.高并发.to

RabbitMQ 集群与高可用配置

RabbitMQ 集群与高可用配置 集群概述 通过 Erlang 的分布式特性(通过 magic cookie 认证节点)进行 RabbitMQ 集群,各 RabbitMQ 服务为对等节点,即每个节点都提供服务给客户端连接,进行消息发送与接收. 这些节点通过 RabbitMQ HA 队列(镜像队列)进行消息队列结构复制.本方案中搭建 3 个节点,并且都是磁盘节点(所有节点状态保持一致,节点完全对等),只要有任何一个节点能够工作,RabbitMQ 集群对外就能提供服务. 环境 · CentOS 6

Redis 哨兵集群实现高可用

哨兵的介绍 sentinel,中文名是哨兵.哨兵是 redis 集群机构中非常重要的一个组件,主要有以下功能: 集群监控:负责监控 redis master 和 slave 进程是否正常工作. 消息通知:如果某个 redis 实例有故障,那么哨兵负责发送消息作为报警通知给管理员. 故障转移:如果 master node 挂掉了,会自动转移到 slave node 上. 配置中心:如果故障转移发生了,通知 client 客户端新的 master 地址. 哨兵用于实现 redis 集群的高可用,本身

Redis集群与高可用

Redis集群 redis cluster 是redis官方提供的分布式解决方案,在3.0版本后推出的,有效地解决了redis分布式的需求,当一个redis节点挂了可以快速的切换到另一个节点.当遇到单机内存.并发等瓶颈时,可以采用分布式方案要解决问题. 分布式redis数据库 1.分区和槽slot redis cluster中有一个16384(2^4 * 2^10)长度的槽的概念.通过哈希算法再加上取模运算可以将一个值固定地映射到某个区间,区间由连续的slot组成. redis cluster采

在CentOS7上配置RabbitMQ 3.6.3集群与高可用

在CentOS7上配置RabbitMQ 3.6.3集群与高可用 集群概述 通过 Erlang 的分布式特性(magic cookie 认证节点)进行 RabbitMQ 集群,各 RabbitMQ 服务为对等节点,即每个节点都提供服务给客户端连接,进行消息发送与接收. 这些节点通过 RabbitMQ HA 队列(镜像队列)进行消息队列结构复制.本文中搭建 3 个节点,并且都是磁盘节点(所有节点状态保持一致,节点完全对等),只要有任何一个节点能够工作,RabbitMQ 集群对外就能提供服务. 环境