zyredis介绍
zyredis是一个基于redis官方客户端扩展的新的redis client，在功能上提供了redis proxy的failover机制并提供了统一管理redis key的model，还专门为python用户提供了pythonic接口处理redis。
zyredis特性：
对redis客户端所有的批量操作进行优化，最大程度上避免redis server阻塞操作。具体优化的redis慢查询有：mget，lrange，pipeline等批量操作，主要优化方式是对单个指令批量操作的逻辑统一进行切片分步执行，避免异步单线程执行的redis-server阻塞。
基于QConf构建failover机制。
公司内部线上业务对redis的依赖非常严重，几乎全量内容相关的业务都基于redis来构建实时接口，但是redis单机超20G后就会存在性能瓶颈，因此我们引入codis集群统一管理线上redis，codis可以参考官方文档介绍，其codis-proxy本身是无状态的，因此为了使线上服务达到高可用性codis-proxy线上启动的个数大于等于2，当线上某个proxy节点失效为了保证集群的高可用这个时候就需要用到failover机制来保证这一点了。
选择使用QConf而不是Zookeeper的原因？
选择使用QConf而不是zookeeper是从公司当前使用的技术栈考虑的，公司大范围的应用基本都是python和php，公司内使用python构建应用的方式全部都是nginx+后端多进程，如下图展示
公司内部部署php应用主要是通过fastcgi后端多个php-fpm进程，这种部署架构方式对python的影响就是python如果再启动一个线程去维护与zookeeper的通信会由于python语言本身GIL的限制导致阻塞发生，对php的影响更明显因为php压根在语言层面不支持启动线程去维护这样的长连接。这时候使用QConf来生成一块共享内存既满足业务上获取配置的条件又免去与zookeeper通信的开销。
提供codis兼容性支持
codis-proxy对redis命令的支持并不是100%，redis很多命令在codis-proxy客户端上不能使用比如pipeline，如果支持使用pipeline会直接异常，由于codis是中途引入到项目中，之前项目里有大量代码直接基于redis client来构建，为了减去大量修改引入一个中间的client做适配是最简单有效的解决方案。
提供model层
在项目比较大，深度使用redis的场景会有一个这样的问题就是redis的key散落到项目代码中不易管理，因此迫切需要一个专门处理redis相关key的逻辑部件，这就是zyredis提供Model机制的原因，通过使用zyredis的model层功能可以很容易的处理各个redis的key散落在项目代码里面不易管理的场景。
zyredis线上应用情况：
公司内部对外提供内容的业务部分全量使用zyredis客户端提供服务。接口日总请求量大于5亿，redis每天总请求量大于25亿次，codis-proxy低峰期间OPS在2W/s公司目前已经将zyredis做为整体codis-proxy的python版本指定客户端，其他部门也正在迁移。
QConf的管理后台对codis-proxy的配置举例：
qconf后台管理需要创建一个codis-proxy的节点路径如下图展示
图中service/codis路径下有两个节点分别是codis-proxy的配置项，点击查看节点信息如下图
图中redis://192.168.6.184:6389/cps_codis?weight=0和redis://192.168.6.184:6389/cps_codis?weight=2分别为proxy的配置，其中weight代表权重。zyredis会根据权重配置项自动处理。