Redis 代理服务Twemproxy

1、twemproxy explore

当我们有大量 Redis 或 Memcached 的时候，通常只能通过客户端的一些数据分配算法（比如一致性哈希），来实现集群存储的特性。虽然Redis 2.6版本已经发布Redis Cluster，但还不是很成熟适用正式生产环境。 Redis 的 Cluster 方案还没有正式推出之前，我们通过 Proxy 的方式来实现集群存储。

Twitter，世界最大的Redis集群之一部署在Twitter用于为用户提供时间轴数据。Twitter Open Source部门提供了Twemproxy。

Twemproxy,也叫nutcraker。是一个twtter开源的一个redis和memcache代理服务器。 redis作为一个高效的缓存服务器，非常具有应用价值。但是当使用比较多的时候，就希望可以通过某种方式 统一进行管理。避免每个应用每个客户端管理连接的松散性。同时在一定程度上变得可以控制。

Twemproxy是一个快速的单线程代理程序，支持Memcached ASCII协议和更新的Redis协议：

它全部用C写成，使用Apache 2.0 License授权。项目在Linux上可以工作，而在OSX上无法编译，因为它依赖了epoll API.

Twemproxy 通过引入一个代理层，可以将其后端的多台 Redis 或 Memcached 实例进行统一管理与分配，使应用程序只需要在 Twemproxy 上进行操作，而不用关心后面具体有多少个真实的 Redis 或 Memcached 存储。

2、twemproxy特性：

    • 支持失败节点自动删除

      • 可以设置重新连接该节点的时间
      • 可以设置连接多少次之后删除该节点
      • 该方式适合作为cache存储
    • 支持设置HashTag
      • 通过HashTag可以自己设定将两个KEYhash到同一个实例上去。
    • 减少与redis的直接连接数
      • 保持与redis的长连接
      • 可设置代理与后台每个redis连接的数目
    • 自动分片到后端多个redis实例上
      • 多种hash算法：能够使用不同的策略和散列函数支持一致性hash。
      • 可以设置后端实例的权重
    • 避免单点问题
      • 可以平行部署多个代理层.client自动选择可用的一个
    • 支持redis pipelining request

      支持请求的流式与批处理，降低来回的消耗

    • 支持状态监控
      • 可设置状态监控ip和端口，访问ip和端口可以得到一个json格式的状态信息串
      • 可设置监控信息刷新间隔时间
    • 高吞吐量
      • 连接复用，内存复用。
      • 将多个连接请求，组成reids pipelining统一向redis请求。

另外可以修改redis的源代码，抽取出redis中的前半部分，作为一个中间代理层。最终都是通过linux下的epoll 事件机制提高并发效率，其中nutcraker本身也是使用epoll的事件机制。并且在性能测试上的表现非常出色。

3、twemproxy问题与不足

Twemproxy 由于其自身原理限制，有一些不足之处，如：

  • 也不支持select操作

具体的安装步骤可用查看github：https://github.com/twitter/twemproxy

Twemproxy 的安装，主要命令如下：

  1. apt-get install automake
  2. apt-get install libtool
  3. git clone git://github.com/twitter/twemproxy.git
  4. cd twemproxy
  5. autoreconf -fvi
  6. ./configure --enable-debug=log
  7. make
  8. src/nutcracker -h

通过上面的命令就算安装好了，然后是具体的配置，下面是一个典型的配置

  • listen: 127.0.0.1:6379 #使用哪个端口启动Twemproxy
  • redis: true #是否是Redis的proxy
  • hash: fnv1a_64 #指定具体的hash函数
  • distribution: ketama #具体的hash算法
  • auto_eject_hosts: true #是否在结点无法响应的时候临时摘除结点
  • timeout: 400 #超时时间（毫秒）
  • server_retry_timeout: 2000 #重试的时间（毫秒）
  • server_failure_limit: 1 #结点故障多少次就算摘除掉
  • servers: #下面表示所有的Redis节点（IP:端口号:权重）
  • - 127.0.0.1:6380:1
  • - 127.0.0.1:6381:1
  • - 127.0.0.1:6382:1
  • redis2:
  • listen: 0.0.0.0:10000
  • redis: true
  • hash: fnv1a_64
  • distribution: ketama
  • auto_eject_hosts: false
  • timeout: 400
  • servers:
  • - 127.0.0.1:6379:1
  • - 127.0.0.1:6380:1
  • - 127.0.0.1:6381:1
  • - 127.0.0.1:6382:1

你可以同时开启多个 Twemproxy 实例，它们都可以进行读写，这样你的应用程序就可以完全避免所谓的单点故障。

时间： 2024-11-02 21:19:36

Redis 代理服务Twemproxy的相关文章

Redis集群~StackExchange.redis连接Twemproxy代理服务器

回到目录 本文是Redis集群系列的一篇文章,主要介绍使用StackExchange.Redis进行Twemproxy(文中简称TW)代理服务的连接过程,事务上,对于TW来说,我们需要理解一下它的物理架构,它类似于Nugix,主要实现的是请求转发,但它还有一个重要的功能,那就是自动分片,这对于大数据是很必要的,你的服务器需要横向扩展时,不需要告诉客户端,这是一种很理解化的设计模式,当然,也对于Redis来说,在配置TW之后,是可以被全美支持的! 关于tw和Redis集群的设计图 关于StackE

Redis/Memcache代理服务Twemproxy简介

作者:zhanhailiang 日期:2014-12-14 简介 twemproxy,也叫nutcracker,是twtter开源的Redis和Memcache代理服务器. 功能 Fast. Lightweight. Maintains persistent server connections. Keeps connection count on the backend caching servers low. Enables pipelining of requests and respon

高性能的Redis代理TwemProxy

TwemProxy是一个Redis的中间件代理,具有很多有用的功能,可以暂时替代一部分Redis Cluster的功能: 2  支持失败节点自动删除 2  可以设置重新连接该节点的时间 2  可以设置连接多少次之后删除该节点 2  该方式适合作为cache存储 2  支持设置HashTag 2  通过HashTag可以自己设定将两个KEY hash到同一个实例上去. 2  减少与redis的直接连接数 2  保持与redis的长连接 2  可设置代理与后台每个redis连接的数目 2  自动分片

Redis/SSDB+Twemproxy的配置与使用（Mac/Linux平台）

对于redis而已,相信不少的后台开发人员一直都在使用,相比memcache而已,redis不仅可以作为key-value缓存使用,而且提供了丰富的数据结构如set.list.map等,能够实现很多复杂的功能,但是Redis本身主要作用是内存缓存,不适合做持久化存储到磁盘,所以目前出现了很多基于磁盘存储的组件,如:SSDB.ARDB. LevelDB.LMDB.beansDB等 Twemproxy是一个Redis/Memcached代理中间件,可以实现诸如分片逻辑.HashTag.减少连接数等功

redis集群+twemproxy

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

Redis集群方案（来自网络）

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

Redis Twemproxy

主从复制+哨兵解决了读性能和高可用问题,但没有解决写性能问题. Twemproxy将写请求分配到不同节点处理. Twemproxy是Twitter开源的一个redis和memcache代理服务器. 允许用户将多个redis服务器添加到一个服务器池里面,并通过用户选择的散列函数和分布函数,将来自客户端的命令请求分发给服务器池中的各个服务器; 通过使用twemproxy我们可以将数据库分片到多台redis服务器上面,并使用服务器来分担系统压力以及数据库容量,在服务器硬件条件相同的情况下,对于一个包含

Redis集群解决方案-Codis

Codis由豌豆荚于2014年11月开源,基于go和c开发,是近期涌现的.国人开发的优秀开源软件之一,稳定性极高,性能更是改善了很多. Codis由四部分组成: codis-proxy:codis-proxy是客户端连接的Redis代理服务,codis-proxy本身实现了Redis协议,表现得和一个原生Redis没什么区别,对于一个业务来说,可以部署多个codis-proxy,codis-proxy本身是无状态的 codis-config:codis-config是Codis的管理工具,支持添

redis的分布式解决方式--codis （转）

codis是豌豆荚开源的分布式server.眼下处于稳定阶段. 原文地址:https://github.com/wandoulabs/codis/blob/master/doc/tutorial_zh.md Codis 是一个分布式 Redis 解决方式, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的差别 (不支持的命令列表), 上层应用能够像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作