Twemproxy 测试Redis集群架构

Twemproxy 测试架构

twemproxy- nutcracker:

ip:10.207.101.101

ip:10.207.101.102

VIP:10.207.101.100

HA- keepalived

ip:10.207.101.101

ip:10.207.101.102

VIP:10.207.101.100

Redis

IP: 10.207.101.101

Port:6001/6002/6003

IP: 10.207.101.102

Port:6001/6002/6003

1、twemproxy是twitter开发的一个redis代理proxy。通过Twemproxy可以使用多台服务器来水平扩张redis服务,可以有效的避免redis单点故障问题。

使用Twemproxy 对硬件资源配置较高;在redis性能有一定的损失(twitter测试约20%)用于提高整个系统的HA;

2、twemproxy部署简单快捷;可以直接在proxy进行读写、并转发请求给后端的redis;但是不适合超大流量系统。做的时候把应用分开、使用LVS集群:实现twemproxy的负载均衡,提高proxy的可用性和可扩张能力;

3、安装部署

wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz

wget https://codeload.github.com/twitter/twemproxy/zip/master

yum install gcc gcc-c++ tcl ruby -y

tar -xf autoconf-2.69.tar.gz

cd autoconf-2.69/

./configure

make &&make install

unzip unzip master.zip

cd twemproxy-master

autoreconf -fvi

./configure --enable-debug=full

make

make install

4、配置示例:

# vim /etc/nutcracker.yml

alpha:

listen: 0.0.0.0:22121

hash: fnv1a_64

distribution: ketama

auto_eject_hosts: true

redis: true

server_retry_timeout: 2000

server_failure_limit: 1

servers: --两台redis服务器的地址和端口

- 10.207.141.142:6379:1

- 10.207.141.142:6379:1

5、启动Twemproxy服务

nutcracker -t nutcracker.yml

检测配置语法真确会显示OK .

# nutcracker -t twemproxy/conf/nutcracker.yml

nutcracker: configuration file ‘conf/nutcracker.yml‘ syntax is ok

6、设置启动:

cat start.sh

nutcracker -d -c /opt/twemproxy-master/conf/nutcracker.yml -p /opt/twemproxy-master/run/redisproxy.pid -o /opt/twemproxy-master/run/redisproxy.log

cat stop.sh

ps -ef | grep redis | grep -v grep | awk ‘{print $2}‘  | sed -e "s/^/kill -9 /g" | sh -

7、检测进程

ps -ef | grep nutcracker | grep -v grep

8、keepalived 部署 HA 静态路由单点故障;

yum install keepalived -y

# cat /etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {

router_id LVS_DEVEL

}

vrrp_script check_twem {

#    script "killall -0 redis"

script "/etc/keepalived/check_twem.sh"

interval 2

weight -3

fall 3

rise 2

}

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 51

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

172.27.101.100/24 dev eth0 label eth0:1

}

track_script {

check_twem

}

}

virtual_server 172.27.101.100 22121 {

delay_loop 6

protocol TCP

real_server 172.27.101.101 22121 {

weight 1

TCP_CHECK {

connect_timeout 3

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

real_server 172.27.101.102 22121 {

weight 1

TCP_CHECK {

connect_timeout 3

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

}

}

9、nutcracker 进程检测  脚本check_twem.sh

# cat /etc/keepalived/check_twem.sh

#!/bin/bash

counter=$(ps -C nutcracker --no-heading|wc -l)

if [ "${counter}" = "0" ]; then

sh /opt/twemproxy-master/start.sh

sleep 2

counter=$(ps -C nutcracker --no-heading|wc -l)

if [ "${counter}" = "0" ]; then

/etc/init.d/keepalived stop

fi

fi

10、Set测试:

通过twemproxy测试:

# redis-benchmark -h 10.207.101.100 -p 22121 -c 11 -t set -d 11 -l –q

SET: 38167.94 requests per second

直接对后端redis测试:

# redis-benchmark -h 10.207.101.101 -p 6001 -c 11 -t set -d 11 -l –q

直接对后端redis测试:

# redis-benchmark -h 10.207.101.102 -p 6001 -c 11 -t set -d 11 -l –q

SET: 53191.49 requests per second

Get测试:

通过twemproxy测试:

# redis-benchmark -h 0.207.101.100 -p 22121 -c 11 -t get -d 11 -l -q

GET: 37453.18 requests per second

直接对后端redis测试:

# redis-benchmark -h 0.207.101.101 -p 22121 -c 11 -t get -d 11 -l -q

GET: 62111.80 requests per second

查看键值分布:

# redis-cli info|grep db0

db0:keys=51483,expires=0,avg_ttl=0

# redis-cli info|grep db0

db0:keys=48525,expires=0,avg_ttl=0

11 、redis-cli 基本操作;

Redis 模糊搜索

keys *

select 2

删除所有以user开头的key 可以这样实现:

# redis-cli keys "user*"

1) "user1"

2) "user2"

# redis-cli keys "user*" | xargs redis-cli del

(integer) 2

# 删除成功

# 批量删除匹配通配符的key用到了Linux中的管道和xargs参数:

redis-cli keys "s*" | xargs redis-cli del

# 如果需要制定数据库,需要用到 -n 数据库编号   参数,下面是删除2数据库中s开头的键:

redis-cli -n 2 keys "s*" | xargs redis-cli -n 2 del

redis-cli keys "*" | xargs redis-cli del

# 如果redis-cli没有设置成系统变量,需要指定redis-cli的完整路径

# 如:/opt/redis/redis-cli keys "*" | xargs /opt/redis/redis-cli del

# 删除当前数据库中的所有Key

flushdb

# 删除所有数据库中的key

flushall

时间: 2024-10-28 21:16:48

Twemproxy 测试Redis集群架构的相关文章

laravel项目利用twemproxy部署redis集群的完整步骤

Twemproxy是一个代理服务器,可以通过它减少Memcached或Redis服务器所打开的连接数.下面这篇文章主要给大家介绍了关于laravel项目利用twemproxy部署redis集群的相关资料,文中通过示例代码介绍的非常详细,需要的朋友可以参考下 前言 twemproxy是twitter开发的一个redis代理proxy,Twemproxy可以把多台redis server当作一台使用,开发人员通过twemproxy访问这些redis servers 的时候不用关心到底去哪一台redi

基于Twemproxy的Redis集群方案

概述 由于单台redis服务器的内存管理能力有限,使用过大内存redis服务器的性能急剧下降,且服务器发生故障将直接影响大面积业务.为了获取更好的缓存性能及扩展型,我们将需要搭建redis集群来满足需求.因redis 3.0 beta支持的集群功能不适合生产环境的使用,所以我们采用twitter正在使用的twemproxy来搭建redis缓存服务器集群,目前用户包括Pinterest.Tumblr.Twitter.Vine.Kiip.Wuaki.tv.Wanelo.Kontera.Wikimed

基于 twemproxy 搭建 redis 集群

概述 由于单台redis服务器的内存管理能力有限,使用过大内存redis服务器的性能急剧下降,且服务器发生故障将直接影响大面积业务.为了获取更好的缓存性能及扩展型,我们将需要搭建redis集群来满足需求.因redis 3.0 beta支持的集群功能不适合生产环境的使用,所以我们采用twitter正在使用的twemproxy来搭建redis缓存服务器集群,目前用户包括Pinterest.Tumblr.Twitter.Vine.Kiip.Wuaki.tv.Wanelo.Kontera.Wikimed

Redis集群架构

Redis集群概述 集群的核心意义只有一个:保证一个节点出现了问题之后,其他的节点可以继续提供服务使用. Redis基础部分讲解过主从配置:对于主从配置可以有两类:一主二从,层级关系.开发者一主二从是常用的手段. Redis的主从配置是所有Redis集群的一个基础.但是只是依靠主从依然无法实现高可用的配置. Redis集群有以下两种方案 1)keepalived+twemproxy+HAProxy+sentinel 对redis集群而言,首先在主从的基础上发展出了一个叫哨兵的处理机制,所谓的哨兵

redis 集群架构 cluster 、sentinel

redis-cluster 实验环境: centos6.5   IP:192.168.1.11 依赖包:redis    ruby   rubygem     [[email protected] redis]#tar xf redis-3.0.2.tar.gz [[email protected] redis]#cd redis-3.0.2 [[email protected] redis]#make &&make install 用tab键看redis-  这些工具是否安装好,没安装则

redis集群+twemproxy

参考: https://www.zhihu.com/question/21419897 http://www.cnblogs.com/haoxinyue/p/redis.html 为什么集群? 通常,为了提高网站响应速度,总是把热点数据保存在内存中而不是直接从后端数据库中读取.Redis是一个很好的Cache工具.大型网站应用,热点数据量往往巨大,几十G上百G是很正常的事儿,在这种情况下,如何正确架构Redis呢? 首先,无论我们是使用自己的物理主机,还是使用云服务主机,内存资源往往是有限制的,

基于twemproxy和vip实现redis集群的无感知弹性扩容

目标是实现redis集群的无感知弹性扩容 关键点 1.是无感知,即对redis集群的用户来说服务ip和port保持不变 2.弹性扩容,指的是在需要时刻可以按照业务扩大redis存储容量. 1.业务场景 1.redis集群某个业务容量不足,需要扩容 2.redis集群需要一个为一个新业务分配存储容量 3.redis集群在扩容的时候服务不是停止的,而是服务中,即无感知 最好的解决方式 对客户端无感知,即客户端不需要任何操作就实现了redis集群的扩容 2.最朴素的twemproxy+redis集群架

Redis集群技术及Codis实践

"高效运维最佳实践"是InfoQ在2015年推出的精品专栏,由触控科技运维总监萧田国撰写,InfoQ总编辑崔康策划. 前言 如开篇文章所言,高效运维包括管理的专业化和技术的专业化.前两篇我们主要在说些管理相关的内容,本篇说一下技术专业化.希望读者朋友们能适应这个转换,谢谢. 互联网早在几年前就已进入Web 2.0时代,对后台支撑能力的要求,提高了几十倍甚至几百倍.在这个演化过程中,缓存系统扮演了举足轻重的角色. 运维进化到今天,已经不是重复造轮子的时代.所以,我们在架构优化和自动化运维

Redis集群方案(来自网络)

参考: https://www.zhihu.com/question/21419897 http://www.cnblogs.com/haoxinyue/p/redis.html 为什么集群? 通常,为了提高网站响应速度,总是把热点数据保存在内存中而不是直接从后端数据库中读取.Redis是一个很好的Cache工具.大型网站应用,热点数据量往往巨大,几十G上百G是很正常的事儿,在这种情况下,如何正确架构Redis呢? 首先,无论我们是使用自己的物理主机,还是使用云服务主机,内存资源往往是有限制的,