twemproxy简介

在大多数情况下，Twemproxy比直接操作 Redis 相比20%的性能损失。 MGET 操作的效率，其性能只有直接操作 Redis 的 50%。避免每个应用每个客户端管理连接的松散性。同时在一定程度上变得可以控制。 Twemproxy是一个快速的单线程代理程序，支持Memcached ASCII协议和更新的Redis协议：依赖了epoll API.

功能

前端使用 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值的情况。

性能

不管 Twemproxy 后端有几台 Redis，前端的单个 Twemproxy 的性能最大也只能和单台 Redis 性能差不多
twemproxy特性

支持失败节点自动删除

可以设置重新连接该节点的时间
可以设置连接多少次之后删除该节点
该方式适合作为cache存储
支持设置HashTag

通过HashTag可以自己设定将两个KEYhash到同一个实例上去。
减少与redis的直接连接数

保持与redis的长连接
可设置代理与后台每个redis连接的数目
自动分片到后端多个redis实例上

多种hash算法（部分还没有研究明白)
可以设置后端实例的权重
避免单点问题

可以平行部署多个代理层.client自动选择可用的一个
支持redis pipelining request

支持状态监控

可设置状态监控ip和端口，访问ip和端口可以得到一个json格式的状态信息串
可设置监控信息刷新间隔时间
高吞吐量

连接复用，内存复用。
将多个连接请求，组成reids pipelining统一向redis请求。
Twemproxy 由于其自身原理限制，有一些不足之处，如：
不支持针对多个值的操作，比如取sets的子交并补等（MGET 和 DEL 除外）
不支持Redis的事务操作
出错提示还不够完善

http://antirez.com/news/44

Twemproxy的项目地址：https://github.com/twitter/twemproxy