Twemproxy(nutcracker)容易误解的参数

发表于 分类于

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

Twemproxy是一个快速的单线程代理程序，支持Memcached ASCII协议和更新的Redis协议：
它全部用C写成，使用Apache 2.0 License授权。项目在Linux上可以工作，而在OSX上无法编译，因为它依赖了epoll API.
Twemproxy 通过引入一个代理层，可以将其后端的多台 Redis 或 Memcached 实例进行统一管理与分配，使应用程序只需要在 Twemproxy 上进行操作，而不用关心后面具体有多少个真实的 Redis 或 Memcached 存储。

由于数据量大，以及考虑到redis的集群和高可用等需求，在项目中采用nutcracker作为redis和memcache的前端proxy。nutcracker的配置文件相当简洁，只有10来个参数。下面是一个典型的配置

1
2
3
4
5
6
7
8
9
10
11
12
13
redis-for-test:
  listen: 0.0.0.0:11212         #表示监听的IP和端口
  redis: true                   #true表示作为redis代理，false表示作为memcache代理  
  hash: fnv1a_64                #指定具体的hash函数
  distribution: ketama          #具体的hash算法
  timeout: 400                  #超时时间（毫秒）
  auto_eject_hosts: true        #是否在结点无法响应的时候临时摘除结点
  server_retry_timeout: 30000   #重试的时间（毫秒）
  server_failure_limit: 2       #结点故障多少次就算摘除掉
  preconnect: true              #在进程启动的时候，是否需要预连接到所有的server，默认值false
  servers:                      #下面表示所有的Redis节点（IP:端口号:权重）
   - 127.0.0.1:6379:1 test-1
   - 127.0.0.1:6380:1 test-2

巧合的事情发生了，前端时间由于机房故障，后端的redis节点中有两台机器挂掉了。理论上这时nutcracker应该会发挥左右。然而实际情况是报警报疯了。难道nutcracker的高可用是随便骗骗人的？应该不至于吧。接下来我在测试机上做了如下测试：

开两个redis节点，端口分别为6379和6380。开一个nutcracker，配置如上。然后写一个python脚本来做数据写入，脚本代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# coding: utf-8

import redis
import time

if __name__ == '__main__':
    r = redis.Redis(host='10.240.129.196', port=22221)
    for i in range(0, 10000000):
        try:
            if r.set('key' + str(i), 'value' + str(i)):
                print 'set key:', i, 'success'
            else:
                print '*** set key:', i, 'failed ***'
            time.sleep(0.5)
        except Exception as e:
            print 'except:', e.message

每隔0.5s写入一个KV。同时监控nutcracker日志（启动nutcracker时可以用-o来指定日志文件）。正常运行一会后，kill掉6379的redis节点，这是会发现脚本返回Connection refused错误，接着正常写入，过了会又会出现Connection refused，每隔一会就会出现两次。nutcracker的日志如下：

1
2
3
4
5
6
7
8
9
10
11
12
[Thu Aug 27 16:57:31 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 16:57:31 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 16:58:01 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 16:58:01 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 16:58:32 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 16:58:32 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 16:59:02 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 16:59:02 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 16:59:32 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 16:59:32 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 17:00:02 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused
[Thu Aug 27 17:00:02 2015] nc_core.c:207 close s 7 '127.0.0.1:6379' on event 001D eof 0 done 0 rb 0 sb 0: Connection refused

仔细观察发现，每大约间隔30s就会出现两次链接失败。对比我们nutcracker的配置，是不是有点明白了？原来是对nutcracker的配置有误解。上面的参数中server_retry_timeout和server_failure_limit是指“每次”失败后的下一次重试时间和重试次数。也就是说，当后端有一个redis节点挂了，nutcracker马上发现以后，回去重试。重试两次（server_failure_limit）失败以后就等30秒（server_retry_timeout）再重试，这个过程一直维持。而每次重试都是用真实得数据包发过去，失败后，数据也就丢失了。所以这个配置下每个失败的节点每隔30s就会有两次数据丢失。

nutcracker的这个做法是为了当挂掉的节点又重新爬起来时能恢复，但是不太明白为何它要用真实的数据去做重连尝试，而不是由nutcracker自己发一个心跳包到失败节点做测试，这样起码不会产生数据丢失的问题。