Redis/Memcached代理服务-Twemproxy
2014-11-04 10:59:54 
阿炯
Twemproxy(又称为nutcracker是一个使用C语言编写的Redis和Memcache代理服务器，通过引入一个代理层来减少对后端缓存服务器的连接数，将应用程序后端的多台Redis或Memcached实例进行统一管理，使应用程序只需要在Twemproxy上进行操作，而不用关心后面具体有多少个真实的Redis或Memcached实例。采用Apache2.0协议授权。
当某个节点宕掉时，Twemproxy可以自动将它从集群中剔除，而当它恢复服务时，Twemproxy也会自动连接。由于是代理，所以Twemproxy会有微小的性能损失。
twemproxy (pronounced "two-em-proxy"), aka nutcracker is a fast and lightweight proxy for memcached and redis protocol. It was primarily built to reduce the connection count on the backend caching servers.
Twemproxy是由Twitter开源出来的缓存服务器集群管理工具，主要用来弥补Redis/Memcached 对集群(cluster)管理的不足。作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。该方案很好的解决了单个Redis实例承载能力的问题，当然Twemproxy本身也是单点，需要用Keepalived做高可用方案。通过Twemproxy可以使用多台服务器来水平扩张redis服务，可以有效的避免单点故障问题。
antirez(Redis作者)写过一篇对twemproxy的介绍，他认为twemproxy是目前Redis分片管理的最好方案，虽然antirez的Redis cluster正在实现并且对其给予厚望，但从现有的cluster实现上还是认为cluster除了增加Redis复杂度，对于集群的管理没有twemproxy来的轻量和有效。
谈到集群管理不得不又说到数据的分片管理(shard)，为了满足数据的日益增长和扩展性，数据存储系统一般都需要进行一定的分片，如传统的MySQL进行横向分表和纵向分表，然后应用程序访问正确的位置就需要找的正确的表。此时数据定向工作一般有三个位置可以放置：
数据存储系统本身支持，Redis Cluster就是典型的试图在数据存储系统上支持分片；
客户端支持，Memcached的客户端对分片的支持就是客户端层面的；
代理支持，twemproxy就是试图在服务器端和客户端中间建代理支持；
命令行选项:
-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块大小，以bytes单位 (default: 16384 bytes)
Features
Fast.
Lightweight.
Maintains persistent server connections.
Keeps connection count on the backend caching servers low.
Enables pipelining of requests and responses.
Supports proxying to multiple servers.
Supports multiple server pools simultaneously.
Shard data automatically across multiple servers.
Implements the complete memcached ascii and redis protocol.
Easy configuration of server pools through a YAML file.
Supports multiple hashing modes including consistent hashing and distribution.
Can be configured to disable nodes on failures.
Observability through stats exposed on stats monitoring port.
Works with Linux, *BSD, OS X and Solaris (SmartOS)
特性
轻量级、快速
保持长连接
减少了直接与缓存服务器连接的连接数量
使用 pipelining 处理请求和响应
支持代理到多台服务器上
同时支持多个服务器池
自动分片数据到多个服务器上
实现完整的 memcached 的 ASCII 和再分配协议
通过 yaml 文件配置服务器池
支持多个哈希模式，包括一致性哈希和分布
能够配置删除故障节点
可以通过端口监控状态
支持 linux, *bsd,os x 和 solaris
Twemproxy通过nutcracker.yml文件配置
eshop-detail-freeoa:
listen: 127.0.0.1:1111
hash: fnv1a_64
distribution: ketama
timeout:1000
redis: true
servers:
- 127.0.0.1:6379:1 freeoa-redis-01
- 127.0.0.1:6380:1 freeoa-redis-02
eshop-detail-freeoa：redis集群的逻辑名称
listen：twemproxy监听的端口号
hash：hash散列算法
distribution：分片算法，一致性hash，取模等等
timeout：跟redis连接的超时时长
redis：是否是redis，false的话是memcached
servers：redis实例列表，一定要加别名，否则默认使用ip:port:weight来计算分片，如果宕机后更换机器，那么分片就不一样了，因此加了别名后，可以确保分片一定是准确的。
客户端如java/nginx+lua在连接到twemproxy写数据的时候，twemproxy负责将数据分片，写入不同的redis实例。如果某个redis机器宕机，需要自动从一致性hash环上摘掉，等恢复后自动上线。
auto_eject_hosts: true，自动摘除故障节点
server_retry_timeout: 30000，每隔30秒判断故障节点是否正常，如果正常则放回一致性hash环
server_failure_limit: 2，多少次无响应，就从一致性hash环中摘除
主要要解决的问题和缺点
其功能：
通过代理的方式减少缓存服务器的连接数。
自动在多台缓存服务器间共享数据。
通过不同的策略与散列函数支持一致性散列。
通过配置的方式禁用失败的结点。
运行在多个实例上，客户端可以连接到首个可用的代理服务器。
支持请求的流式与批处理，因而能够降低来回的消耗。
其缺点：
不支持针对多个值的操作，比如取sets的子交并补等。
不支持Redis的事务操作。
错误消息、日志信息匮乏，排查问题困难。
其性能：
不管 Twemproxy 后端有几台 Redis，前端的单个 Twemproxy 的性能最大也只能和单台 Redis 性能差不多。虽然使用Twemproxy需要更多的硬件资源和在redis性能有一定的损失(twitter测试约20%)，但是能够提高整个系统的HA也是相当划算的。
功能结论
前端使用 Twemproxy 做代理，后端的 Redis 数据能基本上根据 key 来进行比较均衡的分布。后端一台 Redis 挂掉后，Twemproxy 能够自动摘除。恢复后，Twemproxy 能够自动识别、恢复并重新加入到 Redis 组中重新使用。
Redis 挂掉后，后端数据是否丢失依据 Redis 本身的策略配置，与 Twemproxy 基本无关。
如果要新增加一台 Redis，Twemproxy 需要重启才能生效；并且数据不会自动重新 Reblance，需要人工单独写脚本来实现。
如同时部署多个 Twemproxy，配置文件一致(测试配置为 distribution ：ketama,modula)，则可以从任意一个读取，都可以正确读取 key对应的值。多台 Twemproxy 配置一样，客户端分别连接多台 Twemproxy可以在一定条件下提高性能。根据 Server 数量，提高比例在 110-150%之间。
如原来已经有 2 个节点 Redis，后续有增加 2 个 Redis，则数据分布计算与原来的 Redis 分布无关，现有数据如果需要分布均匀的话，需要人工单独处理。
如果 Twemproxy 的后端节点数量发生变化，Twemproxy 相同算法的前提下， 原来的数据必须重新处理分布，否则会存在找不到key值的情况 。
最新版本：0.4.1
项目主页：https://github.com/twitter/twemproxy
当某个节点宕掉时，Twemproxy可以自动将它从集群中剔除，而当它恢复服务时，Twemproxy也会自动连接。由于是代理，所以Twemproxy会有微小的性能损失。
twemproxy (pronounced "two-em-proxy"), aka nutcracker is a fast and lightweight proxy for memcached and redis protocol. It was primarily built to reduce the connection count on the backend caching servers.
Twemproxy是由Twitter开源出来的缓存服务器集群管理工具，主要用来弥补Redis/Memcached 对集群(cluster)管理的不足。作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。该方案很好的解决了单个Redis实例承载能力的问题，当然Twemproxy本身也是单点，需要用Keepalived做高可用方案。通过Twemproxy可以使用多台服务器来水平扩张redis服务，可以有效的避免单点故障问题。
antirez(Redis作者)写过一篇对twemproxy的介绍，他认为twemproxy是目前Redis分片管理的最好方案，虽然antirez的Redis cluster正在实现并且对其给予厚望，但从现有的cluster实现上还是认为cluster除了增加Redis复杂度，对于集群的管理没有twemproxy来的轻量和有效。
谈到集群管理不得不又说到数据的分片管理(shard)，为了满足数据的日益增长和扩展性，数据存储系统一般都需要进行一定的分片，如传统的MySQL进行横向分表和纵向分表，然后应用程序访问正确的位置就需要找的正确的表。此时数据定向工作一般有三个位置可以放置：
数据存储系统本身支持，Redis Cluster就是典型的试图在数据存储系统上支持分片；
客户端支持，Memcached的客户端对分片的支持就是客户端层面的；
代理支持，twemproxy就是试图在服务器端和客户端中间建代理支持；
命令行选项:
-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块大小，以bytes单位 (default: 16384 bytes)
Features
Fast.
Lightweight.
Maintains persistent server connections.
Keeps connection count on the backend caching servers low.
Enables pipelining of requests and responses.
Supports proxying to multiple servers.
Supports multiple server pools simultaneously.
Shard data automatically across multiple servers.
Implements the complete memcached ascii and redis protocol.
Easy configuration of server pools through a YAML file.
Supports multiple hashing modes including consistent hashing and distribution.
Can be configured to disable nodes on failures.
Observability through stats exposed on stats monitoring port.
Works with Linux, *BSD, OS X and Solaris (SmartOS)
特性
轻量级、快速
保持长连接
减少了直接与缓存服务器连接的连接数量
使用 pipelining 处理请求和响应
支持代理到多台服务器上
同时支持多个服务器池
自动分片数据到多个服务器上
实现完整的 memcached 的 ASCII 和再分配协议
通过 yaml 文件配置服务器池
支持多个哈希模式，包括一致性哈希和分布
能够配置删除故障节点
可以通过端口监控状态
支持 linux, *bsd,os x 和 solaris
Twemproxy通过nutcracker.yml文件配置
eshop-detail-freeoa:
listen: 127.0.0.1:1111
hash: fnv1a_64
distribution: ketama
timeout:1000
redis: true
servers:
- 127.0.0.1:6379:1 freeoa-redis-01
- 127.0.0.1:6380:1 freeoa-redis-02
eshop-detail-freeoa：redis集群的逻辑名称
listen：twemproxy监听的端口号
hash：hash散列算法
distribution：分片算法，一致性hash，取模等等
timeout：跟redis连接的超时时长
redis：是否是redis，false的话是memcached
servers：redis实例列表，一定要加别名，否则默认使用ip:port:weight来计算分片，如果宕机后更换机器，那么分片就不一样了，因此加了别名后，可以确保分片一定是准确的。
客户端如java/nginx+lua在连接到twemproxy写数据的时候，twemproxy负责将数据分片，写入不同的redis实例。如果某个redis机器宕机，需要自动从一致性hash环上摘掉，等恢复后自动上线。
auto_eject_hosts: true，自动摘除故障节点
server_retry_timeout: 30000，每隔30秒判断故障节点是否正常，如果正常则放回一致性hash环
server_failure_limit: 2，多少次无响应，就从一致性hash环中摘除
主要要解决的问题和缺点
其功能：
通过代理的方式减少缓存服务器的连接数。
自动在多台缓存服务器间共享数据。
通过不同的策略与散列函数支持一致性散列。
通过配置的方式禁用失败的结点。
运行在多个实例上，客户端可以连接到首个可用的代理服务器。
支持请求的流式与批处理，因而能够降低来回的消耗。
其缺点：
不支持针对多个值的操作，比如取sets的子交并补等。
不支持Redis的事务操作。
错误消息、日志信息匮乏，排查问题困难。
其性能：
不管 Twemproxy 后端有几台 Redis，前端的单个 Twemproxy 的性能最大也只能和单台 Redis 性能差不多。虽然使用Twemproxy需要更多的硬件资源和在redis性能有一定的损失(twitter测试约20%)，但是能够提高整个系统的HA也是相当划算的。
功能结论
前端使用 Twemproxy 做代理，后端的 Redis 数据能基本上根据 key 来进行比较均衡的分布。后端一台 Redis 挂掉后，Twemproxy 能够自动摘除。恢复后，Twemproxy 能够自动识别、恢复并重新加入到 Redis 组中重新使用。
Redis 挂掉后，后端数据是否丢失依据 Redis 本身的策略配置，与 Twemproxy 基本无关。
如果要新增加一台 Redis，Twemproxy 需要重启才能生效；并且数据不会自动重新 Reblance，需要人工单独写脚本来实现。
如同时部署多个 Twemproxy，配置文件一致(测试配置为 distribution ：ketama,modula)，则可以从任意一个读取，都可以正确读取 key对应的值。多台 Twemproxy 配置一样，客户端分别连接多台 Twemproxy可以在一定条件下提高性能。根据 Server 数量，提高比例在 110-150%之间。
如原来已经有 2 个节点 Redis，后续有增加 2 个 Redis，则数据分布计算与原来的 Redis 分布无关，现有数据如果需要分布均匀的话，需要人工单独处理。
如果 Twemproxy 的后端节点数量发生变化，Twemproxy 相同算法的前提下， 原来的数据必须重新处理分布，否则会存在找不到key值的情况 。
最新版本：0.4.1
项目主页：https://github.com/twitter/twemproxy