Memcache---集群方案

Memcache—集群方案

magent

一、伪集群方案
最常见的做法：memcache安装后，在一台机器或多台机器上启动多个实例，客户端配置memcache节点的ip，port即可。
由客户端实现分布式缓存效果，其实是伪集群。
memcache节点之间不通信，无数据备份，负载均衡由客户端实现，存在单点故障。
客户端可设置故障恢复和故障转移机制。

二、简单集群方案
使用Magent代理组件搭建集群服务。
集群特性：
1）memcache节点宕机后，客户端能自动重连。
2）有数据备份，比如部署了memcache节点1、节点2和备份节点，当节点1宕机，set操作到节点1的时候，会失败（不会自动跳到另一个节点当中去），但备份memcache节点是会保留所有key，所有运用get命令还是能够得到正常结果的。

1、下载安装
1）下载地址：http://memagent.googlecode.com/files/magent-0.6.tar.gz，最新版本为0.6，目前演示用的是magent-0.5版本的。注意目前这个google的地址在国内是无法访问的，只能通过其他方式下载了，相信各位有办法的。也可以在以下地址找到：
http://download.csdn.net/detail/huangying2124/9386872

2）编译安装
1.tar -xzvf magent-0.5.tar.gz
2./sbin/ldconfig
3.sed -i “s#LIBS = -levent#LIBS = -levent -lm#g” Makefile
4.make
5.cp magent /usr/bin/magent
6.magent

执行第三步时，要注意最后的输出文件为Makefile。
执行第四步时，一般会遇到如下错误：
错误一：
这里写图片描述

问题原因：缺少SSIZE_MAX字义
解决方法：
修改ketama.h文件，在文件起始行加下以下代码：
#ifndef SSIZE_MAX
#define SSIZE_MAX 32767
#endif

保存文件，重新执行make命令即可

错误二：
这里写图片描述

这个错误是magent-0.6.tar.gz才有，0.5版本的没有。

问题原因：文件存放路径的问题
libm.a 默认在/usr/lib/x86…/lib64下
libevent.a 默认在/usr/lib/下
本人演示用的Linux操作系统是Centos-6.5，其他操作系统可能不同，请注意区分。

解决办法：
可用find命令查找，再将这两个文件拷贝到/usr/lib64目录下
find -name libm.a
find -name libevent.a

这里写图片描述

这里写图片描述

若libm.a提示找不到，则需要重新安装glibc-static组件：yum install glibc-static。

错误三：
安装过程中出现：/usr/lib64/libevent.a(event 0) : In function ‘gettime’错误字样

解决办法：
1、先备份Makefile文件：cp Makefile Makefile.bak
2、修改Makefile文件，找到CFLAGS = -Wall -g -O2 -I/usr/local/include $(M64)，改为CFLAGS = -lrt -g -O2 -I/usr/local/include $(M64)即可。

make命令成功后，会在当前目录下产生magent文件，将该文件夹移到/usr/bin/目录下即可。

这里写图片描述

文件夹移到新的位置后，可以直接使用magent命令，如下图所示，表示安装成功：
这里写图片描述

这里写图片描述

2、Magent启动命令常用参数
-u：启动用户名
-n：连接数，默认为4096
-l：magent监听的IP地址
-p(小写)：magent监听的端口号
-s：注册的memcache节点信息，格式为ip:port
-b：用于备份的memcache节点信息，格式为ip:port

示例命令 magent -u root -n 2048 -l 192.168.0.103 -p 12001 -s 192.168.0.103:11211 -s 192.168.0.103:11212 -b 192.168.0.103:11213

3、使用示例
1）先启动memcache节点
/usr/local/bin/memcached -d -m 128 -u root -l 192.168.0.103 -p 11211 -P /tmp/memcached11211.pid
/usr/local/bin/memcached -d -m 128 -u root -l 192.168.0.103 -p 11212 -P /tmp/memcached11212.pid
/usr/local/bin/memcached -d -m 128 -u root -l 192.168.0.103 -p 11213 -P /tmp/memcached11213.pid

共启动3个memcache节点，端口分别为11211，11212，11213

2）启动magent，代理memcache节点
magent -u root -n 2048 -l 192.168.0.103 -p 12001 -s 192.168.0.103:11211 -s 192.168.0.103:11212 -b 192.168.0.103:11213

如命令所示：
memcache 11211和11212两个节点为工作节点，11213节点将作为备份节点;
magent监听的端口为12001，ip为192.168.0.103。

注：为了演示方便，都在一台机器上启动实例，若实际需要为多台机器，将ip和端口更换即可。

4、基本使用方法
1）Telnet作为客户端，连接magent
还记得前一遍讲解的Telnet操作吗？magent的操作也一样适用。
演示的ip和port可以参照上面的演示示例。
telnet 192.168.0.103 12001
stats命令查看状态，如下图所示：
这里写图片描述

可以看到magent版本号，连接的memcache工作节点列表，用matrix1、matrix2表示。

2）get，set，version等命令跟memcache的操作是一致的
set操作时，按哈希算法写入两个工作节点（简单映射哈希算法），备份节点不受此哈希算法影响，所有的缓存对象都会到备份节点中存储。
get操作时，先按哈希算法查找，查找不到就到备份节点里查询，因为set时所有的缓存对象都会保存到备份节点上。
当某一memcache工作节点宕机时，set还是按原有的哈希算法做set操作，宕机的节点上无数据，但备份节点上有，get操作还是不受影响的（所以说备份节点很重要，一定要设置）。
当宕机的节点重新启动时，该节点已无数据。magent做get操作时，尽管备份节点上还有数据，但还是会返回空值。（这是一个很大的问题！）

code.google官方最新发布的版本为magent-0.6.tar.gz，也一样没有修复这个问题。

另外附上magent-0.5和magent-0.6的下载地址：
原版：
magent-0.5：http://download.csdn.net/detail/huangying2124/9386870
magent-0.6：http://download.csdn.net/detail/huangying2124/9386872

修正版（修正安装过程中出现SSIZE_MAX无法找到的问题）
magent-0.5：http://download.csdn.net/detail/huangying2124/9386875
magent-0.6：http://download.csdn.net/detail/huangying2124/9386878

Mcrouter

Mcrouter-基于Memcached协议的缓存层流量管理工具（Memcached集群的另一个选择）（转）
Mcrouter 是一个基于Memcached协议的路由器，它是 Facebook缓存架构的核心组件，在峰值的时候，它能够处理每秒50亿次的请求。近日，Facebook开放了Mcrouter的源代码，且遵从BSD协议，希望能够帮助更多的网站使用Mcrouter并扩大其系统规模。因为任何要接入Memcached服务的客户端都会使用标准ASCII编码的Memcached协议，所以对于客户端来说，Mcrouter就像一个Memcached服务器；而对于服务器端来说，Memcached却又像一个普通的Memcached客户端。采用Memcached的通用API作为通信方式如下图所示：

Mcrouter主要特性如下：

支持标准、开源的Memcached ASCII编码协议，使得支持Memcached协议的所有客户端无需做任何修改即可支持Mcrouter。
能够使得客户端共享连接池，达到减少连接个数的目的。
提供了一个非常有效的一致性哈希算法，允许给多个Memcached实例分配哈希值。
能够根据key前缀把客户端分配到不同的Memcached池中。
能够在多个主机上保存一份相同数据的备份。
在测试新缓存设备时，Mcrouter能够路做到从客户端到缓存设备的所有可能路径都可用的。
支持灵活的跟踪配置,通过重新哈希值范围跟踪测试不同大小的Memcached池，或只跟踪哈希值范围的一部分，或在运行时动态修改跟踪环境。
支持热加载配置文件，它会监控所有的配置文件，一旦检测到配置文件被修改,就启动一个后台线程自动地重新加载、分析这些文件，并根据新配置来处理新请求。
支持灵活的路由方式，路由句柄是由小路由模块组合而成，这些路由模块公用一个接口，也可以自由组合，单个路由句柄更容易理解、创建和测试。
支持目的主机的心跳检测和自动故障转移，能够检测每个目的主机的心跳。
允许以主机、池或者集群为单位设置任何请求的速率的阀值,同时也支持限制请求的速度以减缓请求的发送速度，以保障服务质量。
通过一个内核一个线程的方式充分利用了多核系统的优势，在处理异步处理网络事件时，使用了内部的轻量级线程即纤程。
具有丰富的stats和debug命令，并提供了安全可靠的删除操作。
能够通过简单的配置管理大的多集群，还能够根据slab的大小自动分割或重组数据块
能够通过广播操作把请求数据备份到多个Memcached池中或者集群里面。
支持本地和远程缓存两级缓存，自动填充新增缓存以消除新增缓存区造成的性能影响
采用JSON格式的配置，支持通过任意方式的路由处理，以适应各种路由需求。
更多Mcrouter相关信息，请登录其在GitHub上的站点查看，常用示例请参考这里。另外，Mcrouter由Facebook在去年的Data@Scale大会上提出，并于近日开源，即将成为Facebook 在新推出的TODO开源协作联盟当中开源的第一项技术。据Facebook方面介绍，Mcrouter 能够在Facebook遍布全世界的数据中心的服务器集群的缓存层中快速分配调用数据，它具有极强的适应性，峰值时可以达到每秒50亿次的请求。去年，Instagram 数据向Facebook平稳转移就是使用的该技术。

Mcrouter主要使用C++开发，且使用C开发了功能库部分，使用Ragel开发了协议解析部分，使用开源库Folly和Fbthrift处理异步网络。尽管Mcrouter已经开源，但是Facebook仍然一直寻求改进Mcrouter性能的方法（如修复Bug、添加新特性等），并作持续的更新和改进；还会在Github Wiki上维护Mcrouter的文档，同时还建立了一个Facebook讨论组，用来推动Mcrouter项目持续、健康的发展。

参考：

http://www.infoq.com/cn/news/2014/09/mcrouter-memcached（以上内容转自此篇文章）

http://www.oschina.net/translate/introducing-mcrouter-a-memcached-protocol-router-for-scaling-memcached-deployments

https://github.com/facebook/mcrouter/wiki（官方介绍）

https://github.com/facebook/mcrouter/wiki/mcrouter-installation（Ubuntu的安装参考）

链接: https://pan.baidu.com/s/1bMhuZs 密码: 8p8k（Mcrouter中文手册第二章）

分类: 分布式-[集群/方案/工具/设计], 服务器运维-[Linux/Mac/Ubuntu/CentOS/Windows]