twemproxy搭建和简介

twemproxy是 Twitter 开源出来的 Redis 和 Memcached 代理

其功能：

通过代理的方式减少缓存服务器的连接数。

自动在多台缓存服务器间共享数据。

通过不同的策略与散列函数支持一致性散列。

通过配置的方式禁用失败的结点。

运行在多个实例上，客户端可以连接到首个可用的代理服务器。

支持请求的流式与批处理，因而能够降低来回的消耗。

其缺点：

不支持针对多个值的操作，比如取sets的子交并补等。

不支持Redis的事务操作。

错误消息、日志信息匮乏，排查问题困难。

 

-------------------------------------------------------------------------------------

 

那么说一下搭建环境的方法：https://github.com/twitter/twemproxy

To build nutcracker from distribution tarball:

$ ./configure
$ make
$ sudo make install

To build nutcracker from distribution tarball in debug mode:

$ CFLAGS="-ggdb3 -O0" ./configure --enable-debug=full
$ make
$ sudo make install

To build nutcracker from source with debug logs enabled and assertions disabled:

$ git clone [e-mail]:twitter/twemproxy.git
$ cd twemproxy
$ autoreconf -fvi
$ ./configure --enable-debug=log
$ make
$ src/nutcracker -h

我使用的是第一种方法（需要下载他的nutcracker包），原因是服务器基本包缺的太多。

 

 ---------------------------------------------------------------------------

安装完需要配置（我只配置了本地36一台机子，#后边是注释）

 

redis1: #服务器池成员名字

 

  listen: 192.168.6.36:19999 #twemproxy启动端口

 

  hash: fnv1a_64 #具体的hash函数

 

  distribution: ketama #hash算法-如何分布key，关系到均匀分布key的算法，影响命中key等性能，这里是ketama算法

 

  auto_eject_hosts: true #是否在节点无法响应的时候临时找出，区分save data的slave和cache data的slave

 

  redis: true #是否是redis的proxy

 

  server_retry_timeout: 2000 #重试时间ms

 

  server_failure_limit: 1 #节点故障多少次后摘除

 

  servers: # redis节点（ip:端口号:权重）

 

   - 192.168.6.36:6379:1

 

-----------------------------------------------------------------------------------

 

 安装配置完成后，可以用nutcracker -t来检查配置文件

                                        nutcracker -d后天启动服务

                                        nucracker -D和nucracker stat查看代理状态

 

 

------------------------------------------------------------------------------------

 

接下来翻译一下老牛使用nutcracker的心得：

不支持mutiple keys的原因，将这个放在用户设计上，避免从mutiple keys上进行聚合等操作的时间

Currently is AFAIK even more strict than Redis Cluster that instead allows MULTI/EXEC blocks if all the commands are about the same key.

But IMHO it's the way to go, distribute the subset you can distribute efficiently, and pose this as a design challenge early to the user, instead to invest a big amount of resources into "just works" implementations that try to aggregate data from multiple instances, but that will hardly be fast enough once you start to have serious loads because of too big constant times to move data around.

 

在twemproxy中，一些在redis中如get的命令，如果报错，会一直占有这个链接

Twemproxy在errors时，可以监控到error，但是无法做到用其他node代替当前node进行操作，只是发出一个 A SLAVE OF NOONE commond

       twemproxy is already able to monitor instance errors, count the number of errors, and eject the node when enough errors are detected. Well it is a shame it is not able to take slave nodes as alternatives, and instead of eject nodes use the alternate nodes just after sending a SLAVE OF NOONE command. This would turn it into an HA solution as well

 

在twemproxy中，对failover失效转化的处理，是用sentinel configuration有规律的更新服务器表

2) Or alternatively, I would love if it could be able to work in tandem with Redis Sentinel, checking the Sentinel configuration regularly to upgrade the servers table if a failover happened.

 

还有一种替代的方法，是有一个hot-configure,在失败的时候，可是转化到这个配置文件，进行代理操作proxy ASAP

3) Another alternative is to provide a way to hot-configure twemproxy so that on fail overs Sentinel could switch the configuration of the proxy ASAP.

 

贴一些我查看的帖子，很有帮助：

http://blog.nosqlfan.com/html/4147.html

http://antirez.com/news/44

https://github.com/twitter/twemproxy/issues?page=1&sort=created&state=open

https://github.com/twitter/twemproxy

 

 一些在此的专业词汇：failover ， IMHO ，  ASAP ， Redis ， Memcached ， twemproxy ， nutcracker