redis（10）、redis集群twemproxy
redis技术目录twemproxy is a fast, light-weight proxy for memcached and redis。是一个代理redis程序，redis cluster是无中心的基于哈希槽的方案，而twemporxy是自身启动一个代理程序，代理程序为中心，基于一致性哈希算法的方案。
官网是https://github.com/twitter/twemproxy，很多公司用这个方案实现了redis集群，在没有redis cluster方案之前，redis作者也推荐使用twemproxy方案。
主要的优点有：
[*]
速度快
[*]
轻量级
[*]
维护持久的服务器连接
[*]
在后台低消耗缓存redis数据库的连接数
[*]
启用请求和响应的管道
[*]
支持代理到多个服务器
[*]
同时支持多个服务器池
[*]
多个服务器自动分享数据
[*]
实现了完整的 memcached ascii 和 redis 协议.
[*]
服务器池配置简单，通过一个 YAML 文件即可
[*]
支持多个哈希模式，包括一致的哈希和分布
[*]
可配置在失败时禁用某个节点
[*]
通过统计监测端口的可观察性
[*]
支持 Linux, *BSD, OS X and Solaris (SmartOS)
一、配置实现
（1）、twemproxy下载编译
wget https://github.com/twitter/twemproxy/archive/master.zip
unzip master.zip
cd twemproxy
autoreconf -fvi
./configure
make
make install
注：需要autoconf2.6.9以上版本 autoconf下载地址：http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
（2）、单机redis启动
启动三个redis节点
9001、9002、9003
（3）、配置twemproxy nutcracker.yml
redis1:
listen: 127.0.0.1:8000 #监听的端口
redis: true #是否是Redis的proxy
hash: fnv1a_64 #支持的hash算法
distribution: ketama #具体的算法
auto_eject_hosts: true #是否在结点无法响应的时候临时摘除结点
timeout: 4000 #超时时间（毫秒）
server_retry_timeout: 2000 #重试的时间（毫秒）
server_failure_limit: 3 #结点故障多少次就算摘除掉
servers: #下面表示所有的Redis节点（IP:端口号:权重）
- 127.0.0.1:9001:1
- 127.0.0.1:9002:1
- 127.0.0.1:9003:1
（4）、启动twemproxy
src/nutcracker -d conf/nutcracker.yml
（5）、使用redis-cli测试
测试时发现，查看9001,9002,9003的aof文件时，不同的数据会分配到端口redis上，这个也正是基于一致性哈希算法，数据会分配到不同的节点中。也正是实现了数据分片。
二、nutcracker用法与命令选项
Options:
-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)
配置yml文件之后
nutcracker -t nutcracker.yml 可以检测配置文件是否正确
三、twemproxy缺点
[*]虽然可以动态移除节点，但该移除节点的数据就丢失了。
[*]redis集群动态增加节点的时候,twemproxy不会对已有数据做重分布.maillist里面作者说这个需要自己写个脚本实现
[*]性能上的损耗(其实作为代理 必定会有损耗， twemproxy损耗属于很小的级别了)
[*]不支持针对多个值的操作，比如取sets的子交并补等（MGET 和 DEL 除外）
[*]不支持Redis的事务操作
[*]出错提示还不够完善
四、最佳实践
[*]twemproxy缺点中，动态移除不可用的节点，但是该节点的数据丢失了，这个缺点是最致命的，造成了CAP中的A缺失，可用性丢失，最好每个节点后面跟一个从节点，使用Keepalived+VIP，可以故障漂移，从节点自动升级为主节点。保证了高可用性。
[*]性能会稍微有些丢失，既然是代理就是没办法避免的。
[*]不能动态增加节点、删除节点，这个还要运维自行实现了，重启集群，不过这种操作本身也最好需要重启，分配新的集群集群。
页:
[1]