Redis Twemproxy

主从复制+哨兵解决了读性能和高可用问题,但没有解决写性能问题。

Twemproxy将写请求分配到不同节点处理。

Twemproxy是Twitter开源的一个redis和memcache代理服务器。

允许用户将多个redis服务器添加到一个服务器池里面,并通过用户选择的散列函数和分布函数,将来自客户端的命令请求分发给服务器池中的各个服务器;

通过使用twemproxy我们可以将数据库分片到多台redis服务器上面,并使用服务器来分担系统压力以及数据库容量,在服务器硬件条件相同的情况下,对于一个包含N台redis服务器的池来说,池中每台平均1/N的客户端接收命令请求;

向池里添加更多的服务器可以线性的扩展系统处理命令请求的能力,以及系统能够保存的数据量;

Twemproxy安装配置

Twemproxy可以去github下载
https://github.com/twitter/twemproxy
$ tar xf twemproxy-0.4.0.tar.gz

安装autoconf
由于CentOS 6.x autoconf版本太低,不用yum安装,手动安装
# tar xf autoconf-2.69.tar.gz
# cd autoconf-2.69
# ./configure --prefix=/usr
# make && make install
# autoconf -V #查看是否安装成功

下载automake
automake-1.15.tar.gz
# ./configure --prefix=/usr
# make && make install

下载libtool
libtool-2.4.5.tar.gz
# ./configure --prefix=/usr
# make && make install

安装twemproxy
# tar xf twemproxy-0.4.1.tar.gz
# cd twemproxy-0.4.1
# aclocal
# autoconf
# mkdir config
# autoheader
# libtoolize
# automake -a

# ./configure
# make
# make install

安装完毕

配置文件说明yaml
proxy:
listen: node1:22121
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: true
redis: true
server_retry_timeout: 20000
hash_tag: "{}"
server_failure_limit: 3
servers:
- node1:6379:1
- node2:6379:1
- node3:6379:1

proxy,服务器池的名字,支持创建多个服务器池
listen: node1:22121,这个服务器池的监听地址和端口号
hash: fnv1a_64,键散列算法,用于将键映射为一个散列值
distribution: ketama,键分布算法,决定键被分布到哪个服务器
redis: true,代理redis命令请求,不给定时默认代理memcached请求
servers,池中各个服务器的地址和端口号及权重
auto_eject_hosts、
server_failure_limit: twemproxy连续3次向同一个服务器发送命令请求都遇到错误时,twemproxy就会将该服务器标记为下线,并交由池中其他在线服务器处理

启动redis服务
3个节点手工启动
# service redisd start

启动twemproxy
# nutcracker -d -c /opt/sxt/twemproxy/conf/nutcracker.sxt.yml

连接
# redis-cli -p 22121 -h node1

测试
SET date 2016,这个key落在node1上
SET msg "hello world",这个key落在node2上
SADD numbers 1 3 5 7 9
RPUSH lst a b c d e

Twemproxy散列标签
set user:{001}:name lisi
set user:{001}:age 5
get user:{001}:name
get user:{001}:age
set 001 abc
get 001
set user:001:age 50

Sentinel和Twemproxy整合

redis-mgr

官网说明:https://github.com/changyibiao/redis-mgr

整合了:

redis
redis-sentinel
twemproxy

redis-twemproxy-agent

官网说明:https://github.com/Stono/redis-twemproxy-agent

  https://jambr.co.uk/2013/09/20/redis-twemproxy-agent

时间: 2024-10-13 02:26:53

Redis Twemproxy的相关文章

redis+twemproxy+keepalive集群搭建

redis集群简介: Redis集群是一个实现分布式并且允许单点故障的Redis高级版本. Redis集群没有最重要或者说中心节点,这个版本最主要的一个目标是设计一个线性可伸缩(可随意增删节点?)的功能. Redis集群为了数据的一致性可能牺牲部分允许单点故障的功能,所以当网络故障和节点发生故障时这个系统会尽力去保证数据的一致性和有效性.(这里我们认为节点故障是网络故障的一种特殊情况) 为了解决单点故障的问题,我们同时需要masters 和 slaves. 即使主节点(master)和从节点(s

redis集群+twemproxy

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

redis该如何分区-译文(原创)

写在最前,最近一直在研究redis的使用,包括redis应用场景.性能优化.可行性.这是看到redis官网中一个链接,主要是讲解redis数据分区的,既然是官方推荐的,那我就翻译一下,与大家共享. Partitioning: how to split data among multiple Redis instances. 分区:如何把数据存储在多个实例中. Partitioning is the process of splitting your data into multiple Redi

关于redis集群方案

最近在研究redis集群方案,看到知乎上有个朋友写的观点很好,就先收过来了.原文见:http://www.zhihu.com/question/21419897 为什么集群? 通常,为了提高网站响应速度,总是把热点数据保存在内存中而不是直接从后端数据库中读取.Redis是一个很好的Cache工具.大型网站应用,热点数据量往往巨大,几十G上百G是很正常的事儿,在这种情况下,如何正确架构Redis呢? 首先,无论我们是使用自己的物理主机,还是使用云服务主机,内存资源往往是有限制的,scale up不

Redis中国用户组|唯品会Redis cluster大规模生产实践

嘉宾:陈群 很高兴有机会在Redis中国用户组给大家分享redis cluster的生产实践.目前在唯品会主要负责redis/hbase的运维和开发支持工作,也参与工具开发工作 Outline 一.生产应用场景 二.存储架构演变 三.应用最佳实践 四.运维经验总结 第1.2节:介绍redis cluster在唯品会的生产应用场景,以及存储架构的演变.第3节:redis cluster的稳定性,应用成熟度,踩到过那些坑,如何解决这些问题?这部分是大家比较关心的内容.第4节:简单介绍大规模运营的一些

Redis集群方案(来自网络)

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

Redis 学习(三)redis服务器集群、客户端分片

下面是来自知乎大神的一段说明,个人觉得非常清晰,就收藏了. 为什么集群? 通常,为了提高网站响应速度,总是把热点数据保存在内存中而不是直接从后端数据库中读取.Redis是一个很好的Cache工具.大型网站应用,热点数据量往往巨大,几十G上百G是很正常的事儿,在这种情况下,如何正确架构Redis呢? 首先,无论我们是使用自己的物理主机,还是使用云服务主机,内存资源往往是有限制的,scale up不是一个好办法,我们需要scale out横向可伸缩扩展,这需要由多台主机协同提供服务,即分布式多个Re

redis集群讨论

一.生产应用场景 二.存储架构演变 三.应用最佳实践 四.运维经验总结 第1.2节:介绍redis cluster在唯品会的生产应用场景,以及存储架构的演变.第3节:redis cluster的稳定性,应用成熟度,踩到过那些坑,如何解决这些问题?这部分是大家比较关心的内容.第4节:简单介绍大规模运营的一些经验,包括部署.监控.管理以及redis工具开发. 一.生产应用场景 1.业务范围 redis cluster在唯品会主要应用于后端业务,用作内存存储服务.主要大数据实时推荐/ETL.风控.营销

Redis异构集群数据在线迁移工具Redis-Migrate-Tool【转】

摘要:Redis-Migrate-Tool(后面都简称RMT),是唯品会开源的redis数据迁移工具,主要用于异构redis集群间的数据在线迁移,即数据迁移过程中源集群仍可以正常接受业务读写请求,无业务中断服务时间.这篇blog主要内容包括工具特性简介.使用方法以及注意的要点.关于实现的原理,可以自行阅读源码理解或者联系我们交流. 目前该项目已经开源在GitHub上(https://github.com/vipshop/redis-migrate-tool 链接入口可点击原文阅读). 一.RMT