redis之proxy集群之twemproxy

一 检查集群环境，autoconf和libtool

如果版本太老，可以更新一下，否则安装的时候有问题

rpm -qf /usr/bin/autoconf

autoconf-2.63-5.1.el6.noarch

 

删除当前的rpm包

rpm -e autoconf-2.63-5.1.el6.noarch

tar -zxvf autoconf-2.69.tar.gz

./configure --prefix=/usr

make && make install

 

libtool也是一样，最好2.4版本

 

二 安装twemproxy

twemproxy处于服务器和客户端的中间，将客户端发来的请求，进行一定的处理后，在转发给后端真正的Redis服务器。

也就是说，客户端不直接访问Redis服务器，而是通过twemproxy代理中间件间接访问。

git clone [e-mail]:twitter/twemproxy.git

cd twemproxy

autoreconf -fvi

/configure --prefix=/usr/local/twemproxy--enable-debug=full

make && make install

cp /usr/local/ twemproxy/sbin/nutcracker /usr/sbin

 

如果你是在windows下git clone，然后再传到LINUX服务器的，可能会报错

 

三 配置nutcraker.yml

配置服务器池,首先我们需要明确的是池的名字是随便取的

redis_local:

      listen:192.168.3.200:22121 # 监听网络接口和端口

      hash:md5# hash策略，one_at_a_timemd5 crc16 crc32 crc32a fnv1_64 fnv1a_64 fnv1_32 fnv1a_32 hsieh murmur jenkins

      hash_tag:"{}"

      # 由两个字符组成，一个是hash_tag的开始，另外一个是hash_tag的结束，在hash_tag的开始和结束之间，是将用于计算key的hash值的部分，计算的结果会用于选择服务器。

      # 例如：如果hash_tag被定义为”{}”，那么key值为"memo:{key1}"和" nemo:{key1}"的hash值都是基于” key1”，最终会被映射到相同的服务器。而" memo:key1" 或者nemo:key1将会使用整个key来计算hash，可能会被映射到不同的服务器。

      distribution:ketama

      # 主要是用于选择服务器的算法,选项有：ketama,modula,random

      # ketama一致性hash算法，会根据服务器构造出一个hash ring，并为ring上的节点分配hash范围。ketama的优势在于单个节点添加、删除之后，会最大程度上保持整个群集中缓存的key值可以被重用。

      # modula，根据key值的hash值取模，根据取模的结果选择对应的服务器；

      # random，无论key值的hash是什么，都随机的选择一个服务器作为key值操作的目标；

      auto_eject_hosts:true

      # 是一个boolean值，用于控制twemproxy是否应该根据server的连接状态重建群集。这个连接状态是由server_failure_limit阀值来控制。 默认是false。

 

      redis:true

      # 是一个boolean值，用来识别到服务器的通讯协议是redis还是memcached。默认是false。

      server_retry_timeout:2000

      # 单位是毫秒，控制服务器连接的重试时间间隔，在auto_eject_host被设置为true的时候产生作用。默认是30000 毫秒。

      server_failure_limit:1

      # 控制连接服务器失败的次数，在auto_eject_host被设置为true的时候产生作用。默认是2。如果为0,表示0容忍。

      server_connections:1

      # 每个server可以被打开的连接数。默认，每个服务器开一个连接。这个参数也需要谨慎的使用，对于单个redis-server来说，增加server connection并不能简单的提高并发的性能，因为redis-server本身是单一进程的模型。如果后面是一个具有并发能力的redis-server（比如，aliredis），这个配置的优势就能发挥出来了。

 

      timeout:400 # 单位是毫秒，是连接到server的的超时时间

      backlog:1024 # 监听TCP 的backlog（连接等待队列）的长度，默认是512

      preconnect:true # 是一个boolean值，指示twemproxy是否应该预连接pool中的server。默认是false。

 

      servers:

      -127.0.0.1:6379:1

      #192.168.3.200:7010:10 或者 192.168.3.201: 7011:1 redis-02

      # 一个pool中的服务器的地址、端口和权重的列表，包括一个可选的服务器的名字，如果提供服务器的名字，将会使用它决定server的次序，从而提供对应的一致性hash的hash ring。否则，将使用server被定义的次序。

 

测试配置文件：

nutcracker -t/usr/local/twemproxy/conf/nutcracker.ym

 

四 twemproxy优缺点  

优点：

# 持失败节点自动删除

# 持设置Hash Tag

# 少与redis的直接连接数

# 动分片到后端多个服务器上

# 免单点问题

# 持redis pipeling request,支持请求的流式处理，降低来回的消耗

# 持状态监控

# 接复用，内存复用。 将多个连接请求，组成reids pipelining统一向redis请求，吞吐量较高

 

缺点：

# 不支持针对多个值的操作，比如取sets的子交并补等（MGET 和 DEL 除外）

# 不支持Redis的事务操作

# 也不支持select操作

 

五 启动nutcracker

 

nutcracker -d -c/usr/local/twemproxy/conf/nutcracker.yml -o/usr/local/twemproxy/logs/nutcracker.log -s 22222 -a 192.168.3.200 -i 60000

 

-d 后台运行

-c 指定配置文件

-o 指定输出日志文件

-s 指定统计监控端口号

-a 指定统计监控IP

-i 统计更新间隔，单位毫秒

 

六 测试twemproxy

redis-cli -p 22121