Twemproxy 缓存代理服务器

Twemproxy 缓存代理服务器

 

Twemproxy 概述

Twemproxy（又称为nutcracker）是一个轻量级的Redis和Memcached代理，主要用来减少对后端缓存服务器的连接数。Twemproxy是由Twitter开源出来的缓存服务器集群管理工具，主要用来弥补Redis/Memcached 对集群（cluster）管理的不足。

antirez（Redis作者）写过一篇对twemproxy的介绍，他认为twemproxy是目前Redis 分片管理的最好方案，虽然antirez的Redis cluster正在实现并且对其给予厚望，但从现有的cluster实现上还是认为cluster除了增加Redis复杂度，对于集群的管理没有twemproxy来的轻量和有效。

谈到集群管理不得不又说到数据的分片管理（shard），为了满足数据的日益增长和扩展性，数据存储系统一般都需要进行一定的分片，如传统的MySQL进行横向分表和纵向分表，然后应用程序访问正确的位置就需要找的正确的表。这时候，这个数据定向工作一般有三个位置可以放：

• 数据存储系统本身支持，Redis Cluster就是典型的试图在数据存储系统上支持分片；
• 客户端支持，Memcached的客户端对分片的支持就是客户端层面的；
• 代理支持，twemproxy就是试图在服务器端和客户端中间建代理支持；

 

在三种方案中：

1、客户端方案我认为欠妥，因为这样每个客户端需要维护一定的服务器信息，但是如果动态的增加或减少节点就需要重写配置各个客户端。

2、而在服务器端增加集群管理有利于使用者，减少使用者需要了解的东西，整合集群管理使得性能比其他方案都要更高，但是缺点是其会严重增加代码复杂度，导致服务器端代码爆炸。

3、而采用中间层代理的方式我认为是最优雅和有效的，在不改动服务器端程序的情况下，twemproxy使得集群管理更简单，去除不支持的操作和合并，同时更可以支持多个后端服务，大大减少连接数等等，但是缺点也是显而易见的，它不能更有效的利用集群的优势，如多键运算和范围查找操作等等，这都是需要服务器端程序本身支持。

 

Twemproxy 安装

从源码安装：

git clone git@github.com:twitter/twemproxy.git
cd twemproxy
autoreconf -fvi
./configure --enable-debug=full
make
src/nutcracker -h

 

twemproxy命令行选项：

Usage: nutcracker [-?hVdDt] [-v verbosity level] [-o output file]
[-c conf file] [-s stats port] [-a stats addr]
[-i stats interval] [-p pid file] [-m mbuf size]

-h, –help : 查看帮助文档，显示命令选项
-V, –version : 查看nutcracker版本
-t, –test-conf : 测试配置脚本的正确性
-d, –daemonize : 以守护进程运行
-D, –describe-stats : 打印状态描述
-v, –verbosity=N : 设置日志级别 (default: 5, min: 0, max: 11)
-o, –output=S : 设置日志输出路径，默认为标准错误输出 (default: stderr)
-c, –conf-file=S : 指定配置文件路径 (default: conf/nutcracker.yml)
-s, –stats-port=N : 设置状态监控端口，默认22222 (default: 22222)
-a, –stats-addr=S : 设置状态监控IP，默认0.0.0.0 (default: 0.0.0.0)
-i, –stats-interval=N : 设置状态聚合间隔 (default: 30000 msec)
-p, –pid-file=S : 指定进程pid文件路径，默认关闭 (default: off)
-m, –mbuf-size=N : 设置mbuf块大小，默认64K，含义见下面的零拷贝；

 

零拷贝（Zero Copy）
在twemproxy中，请求和响应都是分配到一块叫mbuf的内存中的，接收请求的mbuf同时会用于转发到backend，类似地，从backend接收响应的mbuf同时也会用于转发到client，这样做就避免了内存拷贝。
此外，mbuf使用内存池，一旦分配就不再释放，当一个请求结束时，它所使用的mbuf会放回内存池。一个mbuf占16K，这个大小需要在I/O性能和连接并发数之间做取舍，mbuf尺寸越大，对socket的读写系统调用次数越少，但整个系统可支持的并发数也越小。如果希望支持更高的client并发请求数，可以把mbuf的尺寸设置小一点（通过-m选项）。

 

Twemproxy 配置

Twemproxy 通过YAML文件配置，例如：

alpha:
  listen: 127.0.0.1:22121
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  redis: true
  server_retry_timeout: 2000
  server_failure_limit: 1
  servers:
   - 127.0.0.1:6379:1

beta:
  listen: 127.0.0.1:22122
  hash: fnv1a_64
  hash_tag: "{}"
  distribution: ketama
  auto_eject_hosts: false
  timeout: 400
  redis: true
  servers:
   - 127.0.0.1:6380:1 server1
   - 127.0.0.1:6381:1 server2
   - 127.0.0.1:6382:1 server3
   - 127.0.0.1:6383:1 server4

gamma:
  listen: 127.0.0.1:22123
  hash: fnv1a_64
  distribution: ketama
  timeout: 400
  backlog: 1024
  preconnect: true
  auto_eject_hosts: true
  server_retry_timeout: 2000
  server_failure_limit: 3
  servers:
   - 127.0.0.1:11212:1
   - 127.0.0.1:11213:1

delta:
  listen: 127.0.0.1:22124
  hash: fnv1a_64
  distribution: ketama
  timeout: 100
  auto_eject_hosts: true
  server_retry_timeout: 2000
  server_failure_limit: 1
  servers:
   - 127.0.0.1:11214:1
   - 127.0.0.1:11215:1
   - 127.0.0.1:11216:1
   - 127.0.0.1:11217:1
   - 127.0.0.1:11218:1
   - 127.0.0.1:11219:1
   - 127.0.0.1:11220:1
   - 127.0.0.1:11221:1
   - 127.0.0.1:11222:1
   - 127.0.0.1:11223:1

omega:
  listen: /tmp/gamma
  hash: hsieh
  distribution: ketama
  auto_eject_hosts: false
  servers:
   - 127.0.0.1:11214:100000
   - 127.0.0.1:11215:1

 

说明：

listen
twemproxy监听地址，支持UNIX域套接字。

hash
可以选择的key值的hash算法：

• one_at_a_time
• md5 
• crc16 
• crc32 (crc32 implementation compatible with libmemcached) 
• crc32a (correct crc32 implementation as per the spec) 
• fnv1_64 
• fnv1a_64，默认选项
• fnv1_32 
• fnv1a_32 
• hsieh 
• murmur 
• jenkins

 

hash_tag
hash_tag允许根据key的一个部分来计算key的hash值。hash_tag由两个字符组成，一个是hash_tag的开始，另外一个是hash_tag的结束，在hash_tag的开始和结束之间，是将用于计算key的hash值的部分，计算的结果会用于选择服务器。

例如：如果hash_tag被定义为”{}”，那么key值为"user:{user1}:ids"和"user:{user1}:tweets"的hash值都是基于”user1”，最终会被映射到相同的服务器。而"user:user1:ids"将会使用整个key来计算hash，可能会被映射到不同的服务器。

 

distribution
存在ketama、modula和random3种可选的配置。其含义如下：

• ketama，一致性hash算法，会根据服务器构造出一个hash ring，并为ring上的节点分配hash范围。ketama的优势在于单个节点添加、删除之后，会最大程度上保持整个群集中缓存的key值可以被重用。
• modula，根据key值的hash值取模，根据取模的结果选择对应的服务器；
• random，无论key值的hash是什么，都随机的选择一个服务器作为key值操作的目标；

timeout

单位是毫秒，是连接到server的超时值。默认是永久等待。

 

backlog
监听TCP 的backlog（连接等待队列）的长度，默认是512。

 

preconnect
是一个boolean值，指示twemproxy是否应该预连接pool中的server。默认是false。

 

redis
是一个boolean值，用来识别到服务器的通讯协议是redis还是memcached。默认是false。

 

server_connections
每个server可以被打开的连接数。默认，每个服务器开一个连接。

 

auto_eject_hosts
是一个boolean值，用于控制twemproxy是否应该根据server的连接状态重建群集。这个连接状态是由server_failure_limit阀值来控制。
默认是false。

 

server_retry_timeout
单位是毫秒，控制服务器连接的时间间隔，在auto_eject_host被设置为true的时候产生作用。默认是30000 毫秒。

 

server_failure_limit
控制连接服务器的次数，在auto_eject_host被设置为true的时候产生作用。默认是2。

 

servers
一个pool中的服务器的地址、端口和权重的列表，包括一个可选的服务器的名字，如果提供服务器的名字，将会使用它决定server的次序，从而提供对应的一致性hash的hash ring。否则，将使用server被定义的次序。

 

 

Twemproxy 监控

Twemproxy 监控端口默认为22222，并每隔30s收集一次信息。

nutcracker --describe-stats

报告的信息如下：

pool stats:
  client_eof          "# eof on client connections"
  client_err          "# errors on client connections"
  client_connections  "# active client connections"
  server_ejects       "# times backend server was ejected"
  forward_error       "# times we encountered a forwarding error"
  fragments           "# fragments created from a multi-vector request"

server stats:
  server_eof          "# eof on server connections"
  server_err          "# errors on server connections"
  server_timedout     "# timeouts on server connections"
  server_connections  "# active server connections"
  requests            "# requests"
  request_bytes       "total request bytes"
  responses           "# responses"
  response_bytes      "total response bytes"
  in_queue            "# requests in incoming queue"
  in_queue_bytes      "current request bytes in incoming queue"
  out_queue           "# requests in outgoing queue"
  out_queue_bytes     "current request bytes in outgoing queue"

 

 

Pipelining

Twemproxy 可以同时接收很多client端的请求，并仅通过一个或几个连接回源，这种结构很适合使用流水线处理请求和响应，从而节省TCP往返时间。
例如，Twemproxy 正在同时代理3个client端的请求，分别是：'get key\r\n'、'set key 0 0 3\r\nval\r\n'和'delete key\r\n' '，Twemproxy 可以将这3个请求打包成一个消息发送给后端的redis： 'get key\r\nset key 0 0 3\r\nval\r\ndelete key\r\n'。

pipelining也是Twemproxy高性能的原因之一。