Redis+TwemProxy(nutcracker)集群方案部署记录

Twemproxy 又称nutcracker ,是一个memcache、Redis协议的轻量级代理,一个用于sharding 的中间件。有了Twemproxy,客户端不直接访问Redis服务器,而是通过twemproxy 代理中间件间接访问。 Twemproxy 为 Twitter 开源产品,简单来说,Twemproxy是Twitter开发的一个redis代理proxy,类似于nginx的反向代理或者mysql的代理工具,如amoeba。Twemproxy通过引入一个代理层,可以将其后端的多台Redis或Memcached实例进行统一管理与分配,使应用程序只需要在Twemproxy上进行操作,而不用关心后面具体有多少个真实的Redis或Memcached存储。

Twemproxy的特性

1)支持失败节点自动删除
   可以设置重新连接该节点的时间
   可以设置连接多少次之后删除该节点
2)支持设置HashTag
   通过HashTag可以自己设定将两个key哈希到同一个实例上去
3)减少与redis的直接连接数
   保持与redis的长连接
   减少了客户端直接与服务器连接的连接数量
4)自动分片到后端多个redis实例上
   多种hash算法:md5、crc16、crc32 、crc32a、fnv1_64、fnv1a_64、fnv1_32、fnv1a_32、hsieh、murmur、jenkins
   多种分片算法:ketama(一致性hash算法的一种实现)、modula、random
   可以设置后端实例的权重
5)避免单点问题
   可以平行部署多个代理层,通过HAProxy做负载均衡,将redis的读写分散到多个twemproxy上。
6)支持状态监控
   可设置状态监控ip和端口,访问ip和端口可以得到一个json格式的状态信息串
   可设置监控信息刷新间隔时间
7)使用 pipelining 处理请求和响应
   连接复用,内存复用
   将多个连接请求,组成reids pipelining统一向redis请求
8)并不是支持所有redis命令
   不支持redis的事务操作
   使用SIDFF, SDIFFSTORE, SINTER, SINTERSTORE, SMOVE, SUNION and SUNIONSTORE命令需要保证key都在同一个分片上。

举个小例子:

你可以把公司前台的MM看作一个proxy,你是个送快递的,你可以通过这个妹子替你代理把你要送达的包裹给公司内部的人,而你不用知道公司每个人座位在哪里。
Twemproxy可以把多台redis server当作一台使用,开发人员通过twemproxy访问这些redis servers 的时候不用关心到底去哪一台redis server读取
k-v数据或者把k-v数据更新到数据集中。

通过Twemproxy可以使用多台服务器来水平扩张redis服务,可以有效的避免单点故障问题。虽然使用Twemproxy需要更多的硬件资源和在redis性能有一定的损失(twitter测试约20%),但是能够提高整个系统的HA也是相当划算的。比如我所在的公司,只使用一台redis server进行读写,但是还有一台slave server一直在同步这台生产服务器的数据。这样做就是为了防止这台单一的生产服务器出现故障时能够有一个"备胎",可以把前端的redis数据读写请求切换到从服务器上,web程序因而不需要直接去访问mysql数据库。再借助于haproxy(又是proxy)或者VIP技术可以实现一个简单的HA方案,可以避免单点故障。但是这种简单的Master-Slave"备胎"方案不能扩张整个redis的容量(如果用系统内存大小衡量,且不考虑内存不足时把数据swap到磁盘上),最大容量由所有的redis servers中最小内存决定的【木桶的短板】。

Twemproxy可以把数据sharding(碎片,这里是分散的意思)到多台服务器的上,每台服务器存储着整个数据集的一部分。因而,当某一台redis服务器宕机了,那么也就失去了一部分数据。如果借助于redis的master-slave replication,能保证在任何一台redis不能工作情况下,仍然能够保证能够存在一个整个数据集的完全覆盖,那么整个redis group(或者称作cluster)仍然能够正常工作。

需要注意的是: Twemproxy不会增加Redis的性能指标数据,据业界测算,使用twemproxy相比直接使用Redis会带来大约10%的性能下降。但是单个Redis进程的内存管理能力有限。据测算,单个Redis进程内存超过20G之后,效率会急剧下降。目前,建议单个Redis最好配置在8G以内;8G以上的Redis缓存需求,通过Twemproxy来提供支持。

----------------------------------------------------------------------------------------------------------------------------------------------------- 下面记录下Redis+Twemproxy(nutcracker)集群部署过程:

先简单看下集群架构

Twemproxy可以把多台redis server当作一台使用,扩大整个redis的容量,开发人员通过twemproxy访问这些redis servers 的时候不用关心到底去哪一台redis server读取k-v数据或者把k-v数据更新到数据集中。

1)集群环境
182.48.115.236    twemproxy-server    安装nutcracker
182.48.115.237    redis-server1       安装redis
182.48.115.238    redis-server2       安装redis

如果在线上使用的话:
中间代理层twemproxy需要2台,并且需要结合keepalived(心跳测试)实现高可用,客户端通过vip资源访问twemproxy。
另外,后面的redis节点也都要做主从复制环境。因为twemproxy会讲数据碎片到每个redis节点上,如果节点挂了,那部分数据就没了。所以最好对每个redis节点机做主从,防止数据丢失。

这里做测试,我只使用一台twemproxy+2个redis节点(不做主从)。

关闭三台机器的iptables防火墙和selinux

2)在两台redis机器上安装并启动redis
可以参考:http://www.cnblogs.com/kevingrace/p/6265722.html

3)在twemproxy-server机器上安装nutcracker

编译安装autoconf
[root@twemproxy-server ~]# wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
[root@twemproxy-server ~]# tar -zvxf autoconf-2.69.tar.gz
[root@twemproxy-server ~]# cd autoconf-2.69
[root@twemproxy-server autoconf-2.69]# ./configure && make && make install

编译安装automake
[root@twemproxy-server ~]# wget http://ftp.gnu.org/gnu/automake/automake-1.15.tar.gz
[root@twemproxy-server ~]# tar -zvxf automake-1.15.tar.gz 
[root@twemproxy-server ~]# cd automake-1.15
[root@twemproxy-server automake-1.15]# ./configure && make && make install

编译安装libtool
[root@twemproxy-server ~]# wget https://ftp.gnu.org/gnu/libtool/libtool-2.4.6.tar.gz
[root@twemproxy-server ~]# tar -zvxf libtool-2.4.6.tar.gz 
[root@twemproxy-server ~]# cd libtool-2.4.6
[root@twemproxy-server libtool-2.4.6]# ./configure && make && make install

编译安装twemproxy
[root@twemproxy-server ~]# wget https://github.com/twitter/twemproxy/archive/master.zip
[root@twemproxy-server ~]# unzip master.zip 
[root@twemproxy-server ~]# cd twemproxy-master
[root@twemproxy-server twemproxy-master]# aclocal
[root@twemproxy-server twemproxy-master]# autoreconf -f -i -Wall,no-obsolete    //执行autoreconf 生成 configure文件等
[root@twemproxy-server twemproxy-master]# ./configure --prefix=/usr/local/twemproxy/
[root@twemproxy-server twemproxy-master]# make && make install

.................................................................................
注意:如果没有安装libtool 的话,autoreconf 的时候会报错,如下:
configure.ac:133: the top level
configure.ac:36: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/local/bin/autoconf failed with exit status: 1
.................................................................................

twemproxy配置:
[root@twemproxy-server ~]# cd /usr/local/twemproxy/
[root@twemproxy-server twemproxy]# ls
sbin  share
[root@twemproxy-server twemproxy]# cp -r /root/twemproxy-master/conf /usr/local/twemproxy/
[root@twemproxy-server twemproxy]# cd conf/
[root@twemproxy-server conf]# ls
nutcracker.leaf.yml  nutcracker.root.yml  nutcracker.yml
[root@twemproxy-server conf]# cp nutcracker.yml nutcracker.yml.bak
[root@twemproxy-server conf]# vim nutcracker.yml
alpha:                                       //这个名称可以自己随意定义
  listen: 182.48.115.236:22121
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  redis: true
  server_retry_timeout: 2000
  server_failure_limit: 1
  servers:                             //这里配置了两个分片
   - 182.48.115.237:6379:1
   - 182.48.115.238:6379:1

[root@twemproxy-server conf]# nohup /usr/local/twemproxy/sbin/nutcracker -c /usr/local/twemproxy/conf/nutcracker.yml &

[root@twemproxy-server conf]# ps -ef|grep nutcracker
root      6407 24314  0 23:26 pts/0    00:00:00 /usr/local/twemproxy/sbin/nutcracker -c /usr/local/twemproxy/conf/nutcracker.yml
root      6410 24314  0 23:26 pts/0    00:00:00 grep nutcracker
[root@twemproxy-server conf]# lsof -i:22121
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
nutcracke 6407 root    5u  IPv4 155109      0t0  TCP localhost:22121 (LISTEN)

4)测试 twemproxy set/get ,后端分片查看

[root@twemproxy-server ~]# redis-cli -h 182.48.115.236 -p 22121
182.48.115.236:22121> 

测试短key - value
[root@twemproxy-server ~]# redis-cli -h 182.48.115.236 -p 22121
182.48.115.236:22121> set wangshibo 666666
OK
182.48.115.236:22121> get wangshibo
"666666"

测试长key - value
182.48.115.236:22121> set huihuihuihuihuihui "hahahahahahahahhahahahahahahahhahahahahahah"
OK
182.48.115.236:22121> get huihuihuihuihuihui 
"hahahahahahahahhahahahahahahahhahahahahahah"

登录两台redis节点上查看,发现已经有分片了
[root@redis-server1 ~]# redis-cli -h 182.48.115.237 -p 6379
182.48.115.237:6379> get wangshibo
"666666"
182.48.115.237:6379> get huihuihuihuihuihui 
"hahahahahahahahhahahahahahahahhahahahahahah"

[root@redis-server2 ~]# redis-cli -h 182.48.115.238 -p 6379
182.48.115.238:6379> get wangshibo
"666666"
182.48.115.238:6379> get huihuihuihuihuihui 
"hahahahahahahahhahahahahahahahhahahahahahah"

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏hadoop学习

DKhadoop安装包下载与监控参数说明

前阶段用了差不多两周的时间把DKhadoop的运行环境搭建以及安装的各个操作都介绍了一遍。关于DKhadoop安装包下载也只是顺带说了一下,但好像大快搜索的服务...

12120
来自专栏Hadoop实操

如何在CDH中配置YARN动态资源池的计划规则

在CDH中使用Yarn的动态资源池,用户会根据时段来区分集群资源的分配情况(如:在夜晚时段集群资源主要倾向于跑批作业,白天时段集群资源主要倾向于业务部门实时计算...

1.8K60
来自专栏Hadoop数据仓库

HAWQ技术解析(十四) —— 高可用性

一、HAWQ高可用简介         HAWQ作为一个传统数仓在Hadoop上的替代品,其高可用性至关重要。通常硬件容错、HAWQ HA、HDFS HA是保持...

314100
来自专栏CSDN技术头条

Java 程序员必备的 IntelliJ IDEA 插件

IntelliJ 在业界被公认为最好的 java 开发工具之一,尤其在智能代码助手、代码自动提示、重构、CVS 整合、代码审查、 创新的 GUI 设计等方面的功...

25450
来自专栏友弟技术工作室

Linux集群系列之一——集群基础概念

集群 场景一 LAMP http,web object简单无状态连接 200,50dynamic prefork,2M ...

36180
来自专栏坚毅的PHP

收集一下用过的linux os

2011-11-09 # uname -a # 查看内核/操作系统/CPU信息 # head -n 1 /etc/issue # 查看操作系统版本 # cat...

36450
来自专栏hadoop学习笔记

DKhadoop安装包下载与DKM监控参数说明

前阶段用了差不多两周的时间把DKhadoop的运行环境搭建以及安装的各个操作都介绍了一遍。关于DKhadoop安装包下载也只是顺带说了一下,但好像大快搜索的服务...

12130
来自专栏pydata

python optimization

首先使用cprofile分析单进程,单线程环境中的性能差的部分,进行算法改写和优化,必要情况下可以通过cpython嵌入c/c++代码。 判断程序为io-b...

8420
来自专栏文渊之博

解决简单恢复模式下产生的日志增长

简介   最近测试服务器进行数据归档,其间程序员发现一个问题,空间不足,我查看原因发现日志文件暴涨。然后将数据库改为简单恢复模式,但是依然存在这个问题。经过查询...

21780
来自专栏网络

分布式系统CAP理论

往期精选 在讨论常见架构前,先简单了解一下CAP理论: CAP是Consistency、Availablity和Partition-tolerance的缩写。分...

25870

扫码关注云+社区

领取腾讯云代金券