一、背景
最近中间件开发组对twemproxy的发现注册机制做了改造，之前没有接触过twemproxy，借这次测试的机会，初步学习了一下twemproxy相关的知识；下面用“测试语言“来做一次梳理（站在测试的角度，掌握哪些技能可以顺利开展测试）。
二、TwemProxy是什么
twemproxy是一种代理分片机制，由Twitter开源。twemproxy作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。该方案很好的解决了单个Redis实例承载能力的问题。通过Twemproxy可以使用多台服务器来水平扩张redis服务，可以有效的避免单点故障问题。虽然使用twemproxy需要更多的硬件资源和在redis性能有一定的损失（twitter测试约20%），但是能够提高整个系统的HA也是相当划算的。当然，twemproxy本身也是单点，需要用Keepalived做高可用方案。
其实twemproxy不光实现了redis协议，还实现了memcached协议，换句话说，twemproxy不光可以代理redis，还可以代理memcached（同样作为缓存服务器，memcached越来越被更少的应用，redis越来越成为更普遍的选择）。
Twemproxy单点架构：
通常会结合keepalived来实现twemproxy的高可用。架构图如下：
上面的架构通常只有一台twemproxy在工作，另外一台处于备机，当一台挂掉以后，vip自动漂移，备机接替工作。
即便我们通过keepalived实现了twemproxy的高可用，也不难发现在整个的redis集群里面，如果用户要想访问redis集群必须通过twemproxy，于是这个时候就有可能造成一种问题：
1，后面的redis集群一定速度暴快，因为一堆的数据库服务
2，所有的性能都卡在了代理上
为了解决上面两个问题，很自然的想到在设计架构时，在twemproxy前面需要一个负载均衡的机制，由此haproxy作为一个千万级高并发负载均衡软件被引入到架构中。
Haproxy的特点：
1，一个开源的
2，高性能的（千万级）
3，基于TCP第四层和http第七层
Haproxy优点：
1，最高可以同时维护40000-50000个并发连接。单位时间内处理最大的请求数为20000.最大数据处理能力可达10GBPS
2，支持多余8种负载均衡算法，同时也支持session保持
3，支持虚拟主机功能
4，拥有服务器性能监控工具
三、TwemProxy能做什么
Antirez（redis作者）写过一篇对twemproxy的介绍，他认为twemproxy是目前Redis 分片管理的最好方案，虽然Antirez的Redis cluster正在实现并且对其给予厚望，但从现有的cluster实现上还是认为cluster除了增加redis复杂度，对于集群的管理没有twemproxy来的轻量和有效。
谈到集群管理不得不又说到数据的分片管理（shard），为了满足数据的日益增长和扩展性，数据存储系统一般都需要进行一定的分片，如传统的MySQL进行横向分表和纵向分表，然后应用程序访问正确的位置就需要找的正确的表。这时候，这个数据定向工作一般有三个位置可以放：
1，数据存储系统本身支持，Redis cluster就是典型的试图在数据存储系统上支持分片
2，客户端支持，memcached的客户端对分片的支持就是客户端层面的
3，代理支持，twemproxy就是试图在服务器端和客户端中间建代理支持
Twemproxy的特性：
- 支持失败节点自动删除
- 可以设置重新连接该节点的时间
- 可以设置连接多少次之后删除该节点
- 支持设置HashTag
- 通过HashTag可以自己设定将两个key哈希到同一个实例上去
- 减少与redis的直接连接数
- 保持与redis的长连接
- 减少了客户端直接与服务器连接的链接数量
- 自动分片到后端多个redis实例上
- 多种hash算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins
- 多种分片算法：ketama(一致性hash算法的一种实现)、modular、random
- 可以设置后端实例的权重
- 避免单节点问题
- 可以平行部署多个代理层，通过HAProxy做负载均衡，将redis的读写分散到多个twemproxy上
- 支持状态监控
- 可设置状态监控IP和端口，访问IP和端口可以得到一个json格式的状态信息串
- 可设置监控信息刷新间隔时间
- 使用pipelining处理请求和响应
- 连接复用，内存服用
- 将多个连接请求，组成redis pipelining统一redis请求
- 并不是支持所有redis命令
- 不支持redis的事务操作
- 使用SIDFF,SDIFFSTORE,SINTER,SINTERSTORE,SMOVE,SUNION and SUNIONSTORE 命令需要保证key都在同一个分片上
最主要功能：用户不再直接操作真正的Redis，而且支持高性能的数据访问，而且支持分片处理，可以操作Redis集群。
四、TwemProxy怎么用
Twemproxy通过配置文件nutcracker.yml来实现对redis集群实现管理。
nutcracker.yml的结构如下：
eshop-detail-test:
listen: 127.0.0.1:1111
hash: fnv1a_64
distribution: ketama
timeout:1000
redis: true
servers:
- 127.0.0.1:6379:1 test-redis-01
- 127.0.0.1:6380:1 test-redis-02
auto_eject_hosts: true
server_retry_timeout: 30000
server_failure_limit: 2
注解：
eshop-detail-test: redis集群的逻辑名称
listen：twemproxy监听的端口号
hash：hash散列算法
distribution：分片算法，一致性hash，取模，等等
timeout：跟redis连接的超时时长
redis：是否是redis，false的话是memcached
servers：redis实例列表，一定要加别名，否则默认使用ip:port:weight来计算分片，如果宕机后更换机器，那么分片就不一样了，因此加了别名后，可以确保分片一定是准确的
auto_eject_hosts: true，自动摘除故障节点
server_retry_timeout: 30000，每隔30秒判断故障节点是否正常，如果正常则放回一致性hash环
server_failure_limit: 2，多少次无响应，就从一致性hash环中摘除
业务方程序（如java/php）连接twemproxy写数据的时候，twemproxy负责将数据分片，写入不同的redis实例。
如果某个redis机器宕机，需要自动从一致性hash环上摘掉，等恢复后自动上线。
五、TwemProxy配合redis的主从模式和哨兵机制
主从模式
只要是进行高可用的架构部署，那么就必须保证多节点，前面提到的redis集群，对于每一个redis节点实际上都采用来主从模式。虽然redis提供了数据持久化的机制，AOF和RDB，但是两种模式解决的是数据容灾，即当redis服务器挂掉时，可以对历史数据进行恢复。AOF模式实际上是生成一个日志文件，当redis服务器重启时，通过读配置文件来恢复历史数据；RDB模式是从redis上实时同步数据到数据库如Myslq，显然两种模式都不能实时的提供历史数据的读，主从模式解决了这一问题。传统的主从模式是一个redis服务器作为master，只负责写入数据，其它几个redis服务器作为slave，只负责读数据，这样就做到了数据的读写分离，也起到了对数据备份的目的。
为什么用主从模式？
最大好处在于：可以自动对数据做备份
有缺点吗？
最大缺点在于：只能够做备份，而出现灾难之后无法立即恢复（还是要使用redis的持久化的机制，使用两者的目的不同，并不矛盾，需要配合使用）
哨兵机制
Redis里面使用了主从模式可以实现多节点配置，但是传统的主从模式的设计有一个缺陷：一旦Master主机出现了问题之后，两台Slave主机将无法提供正常的工作支持，例如：slave主机为只读主机，而且如果要想继续提供支持，那么至少应该通过剩余的几台slave里面去推选出一个新的master，并且最为重要的是，这个新的master还必须能够被用户的程序找到，由此催生了哨兵机制。
哨兵机制(Sentinel) 原理图：
不难看出哨兵机制带来的好处是提升了redis集群的HA(高可用)，哨兵机制也是redis官方推荐的高可用解决方案之一。
哨兵机制(Sentinel) 的功能：
- 监控(Monitoring)，sentinel时刻监控着redis master-slave 是否正常运行；
- 通知(Notification)，sentinel 可以通过api来通知管理员，被监控的 redis master-slave 出现了问题；
- 自动故障转移(Automatic failover)，当redis master出现故障不可用状态，sentinel 会开始一次故障转移，将其中一个slave 提升为新的 master ，将其他的 slave 将重新配置使用新的 master 同步，并使用redis 的服务器应用程序在连接时受到使用新的地址连接；
- 配置提供者(Configuration provider)，sentinel 作为在集群中的权威来源，客户端连接到 sentinel 来获取某个服务的当前 redis 主服务器的地址和其他信息。当前故障转移发生时，sentinel 会报告新地址。
六、本次测试的需求改动点和测试方法
先了解一下中间件开发组twemproxy的实现原理。
php语言实现架构图：
注解：
1，confd是一个客户端，安装在业务方的机器上，作用是从etcd集群中获取twemproxy机器的ip和端口号
2，etcd是一个分布式、可靠的 key-value 存储的分布式系统，当然，它不仅仅用于存储，还提供共享配置及服务发现（可以简单理解成提供服务发现功能的redis）
业务方获取 tw ip 流程：
- Twemproxy 启动时向 etcd 集群注册一个（K,V) 对，key是特定的业务名称+twproxy ip ， value 是 twproxy 的 ip：port ，并且每隔 2 秒向 etcd 集群续活
- 业务方 API 机器启动 confd 去 etcd 集群拉取对应业务下所有key的value，并生成配置文件
- 增加或者删除一个 twproxy 节点时，confd watch 到 etcd 集群相应的 key 发生变化，重新生成配置文件
高可用：
- 每个业务最少提供两个 twemproxy 供业务方连接
- redis 发生主从切换， twemproxy 会实时生成新的配置文件，并重启
提测的改动点：
安装在业务方机器上的confd软件实时与etcd通信，当twproxy与etcd之间网络中断，就会导致twproxy在etcd中的key过期被删除，进而etcd会及时通知confd来删除数据，直至twproxy整个集群的host全部被删除。因此对confd进行二次开发，当confd要求删除所有数据时，屏蔽此要求，并钉钉告警。综上，此次改造的目的是保证业务方至少可以使用1台twproxy服务器。
测试方法：
上面提到了业务方获取 twproxy ip 的流程，即业务方 API 机器启动 confd 去 etcd 集群拉取对应业务下所有key的value，并生成配置文件，然后业务方通过脚本读取配置文件来获取twproxy ip。那么测试思路就是对etcd执行删除的操作，当删除到最后一个（K,V) 对时，查看confd的日志，是否有重新生成配置文件的动作。
测试分解：
etcd执行删除操作：
查看confd的日志：
