您的位置:澳门新葡萄京娱乐网站 > web前端 > Twemproxy——针对MemCached与Redis的代理澳门新葡萄京

Twemproxy——针对MemCached与Redis的代理澳门新葡萄京

2019-12-22 07:04

在去年的QCon London2012 大会上,Twitter 发表了题为 《Timelines @ Twitter》的演讲,里面提到以Redis作为其timeline的主要存储,目前目测全球范围内,Twitter可能是Redis的最大用户了。而今天我们要说的这个Twemproxy,是 Twitter 开源出来的 Redis 和 Memcached 代理。功能介绍我们知道,无论是 Memcached 还是当前的 Redis,其本身都不具备分布式集群特性,当我们有大量 Redis 或 Memcached 的时候,通常只能通过客户端的一些数据分配算法,来实现集群存储的特性。而 Twemproxy 通过引入一个代理层,可以将其后端的多台 Redis 或 Memcached 实例进行统一管理与分配,使应用程序只需要在 Twemproxy 上进行操作,而不用关心后面具体有多少个真实的 Redis 或 Memcached 存储。在 Redis 的 Cluster 方案还没有正式推出之前,通过 Proxy 的方式来实现存储集群可能是最好的选择了。更何况 Twemproxy 是通过 Twitter 自身得到了充分检验的产品。性能根据 Redis 作者的测试结果,在大多数情况下,Twemproxy 的性能相当不错,直接操作 Redis 相比,最多只有20%的性能损失。这对于它带来的好处来说真的是微不足道了。唯一可能还有待改进的是其 MGET 操作的效率,其性能只有直接操作 Redis 的 50%。安装与配置Twemproxy 的安装有点小麻烦,主要命令如下:

4、安装与配置 

具体的安装步骤可用查看github:

Twemproxy 的安装,主要命令如下: 

apt-get install automake
apt-get install libtool
git clone git://github.com/twitter/twemproxy.git
cd twemproxy
autoreconf -fvi
./configure --enable-debug=log
make
src/nutcracker -h

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

redis1:
  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 实例,它们都可以进行读写,这样你的应用程序就可以完全避免所谓的单点故障。 

twemproxy(nutcracker)学习  

你可以同时开启多个 Twemproxy 实例,它们都可以进行读写,这样你的应用程序就可以完全避免所谓的单点故障。问题与不足Twemproxy 由于其自身原理限制,有一些不足之处,如:不支持针对多个值的操作,比如取sets的子交并补等不支持Redis的事务操作出错提示还不够完善更多关于Twemproxy的介绍可以看这里:项目地址:

3、twemproxy问题与不足

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

  • 不支持针对多个值的操作,比如取sets的子交并补等(MGET 和 DEL 除外)
  • 不支持Redis的事务操作
  • 出错提示还不够完善
  • 也不支持select操作

Twemproxy, a Redis proxy from Twitter

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

-

Twemproxy有何用途呢?它可以:

apt-get install automakeapt-get install libtoolgit clone git://github.com/twitter/twemproxy.gitcd twemproxyautoreconf -fvi./configure --enable-debug=logmakesrc/nutcracker -h

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的事件机制。并且在性能测试上的表现非常出色。

Twemproxy – Twitter 开源的 Redis proxy

redis1: listen: 0.0.0.0:9999 #使用哪个端口启动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节点 - 127.0.0.1:6379:1 - 127.0.0.1:6380:1 - 127.0.0.1:6381:1 - 127.0.0.1:6382:1redis2: 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——针对MemCached与Redis的代理

Twemproxy是一个代理服务器,可以通过它减少Memcached或Redis服务器所打开的连接数。

Twemproxy的强大之处在于可以通过配置的方式让它禁用掉失败的结点,同时还能在一段时间后进行重试,抑或使用指定的键->服务器映射。这意味着在将Redis用作数据存储时,它可以对Redis数据集进行分片(禁用掉结点驱逐);在将Redis用作缓存时,它可以启用结点驱逐以实现简单的高可用性。

Twemproxy速度很快,真的很快,它几乎与直接访问Redis速度一样快。我敢说在最差的情况下,性能也只不过才损失20%而已。
我对性能问题唯一的想法是当在多个实例上使用命令时,我觉得MGET还有改进空间。

Twemproxy早在今年初由Twitter开源,它最开始支持Memcached,最近又添加了对Redis的支持。Twitter使用了大量的缓存服务器,每秒会发送300k的tweet;可以看看这篇介绍Real-Time Delivery Architecture At Twitter以了解更多信息。

Redis的创建者Salvatore Sanfilippo(@antirez)撰写了一篇文章,介绍了如何通过Twemproxy在开启Redis-cluster特性前就让Redis集群发挥作用,而在大多数情况下都不会丧失太多的性能:

  • 通过代理的方式减少缓存服务器的连接数
  • 自动在多台缓存服务器间共享数据
  • 通过不同的策略与散列函数支持一致性散列
  • 通过配置的方式禁用失败的结点
  • 运行在多个实例上,客户端可以连接到首个可用的代理服务器
  • 支持请求的流式与批处理,因而能够降低来回的消耗

本文由澳门新葡萄京娱乐网站发布于web前端,转载请注明出处:Twemproxy——针对MemCached与Redis的代理澳门新葡萄京

关键词: