predixy一款高性能全功能redis代理

介绍
redis做为一款优秀的NoSQL表明软件，正变得愈来愈流行，虽然Redis很容易就能够启动并使用，可是要想在线上用好它却也并不是易事。redis的高可用和可扩展不管是自带的Redis Sentinel仍是Redis Cluster都要求客户端进行额外的支持，而目前基本上没有合适的客户端可以作这些事情，实际上客户端来作这些事情也并不合适，它会让维护变得特别困难。所以在客户端和redis服务端之间加一层代理成了一种理想的方案，代理屏蔽后端Redis实现细节向客户端提供redis服务，能够完美的解决Redis的高可用和扩展性问题，同时代理的引入也使得Redis维护变得更加简单。在本文所要介绍的代理predixy以前，已经有几款流行的redis代理，它们各具特点。接下来，咱们就来比较如下代理：

代理 简介

详细功能对比

简单来讲，predixy既支持Redis Sentinel也支持Redis Cluster

后端为Redis Sentinel监控的一组Redis，功能彻底等同于原始Redis
后端为Redis Sentinel监控的多组Redis，则有部分功能受限
后端为Redis Cluster，功能彻底等同于Redis Cluster
性能
做为redis代理，高性能是硬性要求，为了测试上面四款代理的性能接下来咱们就来作个简单的评测，测试平台及各代理具体的版本信息以下：

redis部署：

单线程SET/GET测试
这里单线程是指四款代理都运行在单线程下（下同），redis-benchmark默认并发50个客户端链接，每一个链接每次发送一个命令收到响应后再发下一个命令。这是不少线上实际的场景。

测试命令：
$ redis-benchmark -p xxx -t set,get -r 3000 -n 1000000 -d xxx
测试结果：

结果说明：
在吞吐上，四款代理的性能排列的整齐有序，predixy大幅领先于另外三款代理，而twemproxy又以较大优点领先另外两个，剩下的两个codis在数据量小于512的时候稍稍领先cerberus，而当数据量大于512的时候，codis对cerberus的领先愈来愈大。总体上在数据量达到16KB时，因为redis-benchmark自己成为瓶颈，predixy和twemproxy的SET成绩差很少了。
在延时上，codis因为语言的问题，一直都大于另外三款代理，后续测试也同样。

单线程PIPELINE SET/GET测试
在有些场景下，客户端可能在处理一个请求时可能须要发起屡次redis请求，这时若是把多个redis请求pipeline一块儿请求的话，会大幅改善性能。本轮测试就来看看当客户端一次发送多个请求时咱们各代理表现如何？Redis-benchmark依旧是并发50个链接，可是一次发送20个命令。

测试命令：
$ redis-benchmark -p xxx -t set,get -r 3000 -n 5000000 -P 20 -d xxx
测试结果：

结果说明：
在吞吐上，redis-benchmark一次pipeline 20个命令后，各代理的吞吐量全都猛增。predixy更是一骑绝尘，遥遥领先另外三个，而最后看到在GET 4K数量据的时候predixy表现和其它代理差很少是由于对predixy来讲，当数据量大于2K时redis-benchmark自身已经成为瓶颈。另外三款代理，在上轮测试中落后的cerberus在本轮测试一开始表现远好过twemproxy和codis，但cerberus仍是存在随着数据量变大性能迅速下降的问题。twemproxy和codis在本轮测试中表现基本至关。
在时延上，codis固有的问题表现较差，另外三款在数据量较小时差异较小，而当数据量超过512时，predixy则表现出较明显的优点。

双线程PIPELINE SET/GET测试
测完了单线程，如今咱们开始多线程测试，因为twemproxy不支持多线程，所以twemproxy不参与多线程的测试。考虑到redis-benchmark自己是个单线程程序，在多线程代理下若是咱们再测单个命令的性能，那redis-benchmark极可能就是瓶颈，则没法更明确的看出各代理的性能差别，所以咱们直接测试pipeline，还跟上轮同样，50个并发链接，一次发送20个命令。

测试命令：
$ redis-benchmark -p xxx -t set,get -r 3000 -n 10000000 -P 20 -d xxx
测试结果：

结果说明：
整体趋势和第二轮单线程pipeline测试一致，predixy在本轮测试中依旧取得了领先，不过在开始阶段cerberus和predixy遥遥领先于codis，cerberus和predixy差距不大。可是随着数据量的变大，cerberus再次显示出了性能急剧下降的问题，到1K之后甚至就比codis差了。

结论
在功能的对比上，predixy相比另外三款代理更为全面，基本能够彻底适用原生redis的使用场景。在性能上，predixy在各轮测试中都以较大优点领先。对各代理的总结以下：

predixy：功能全面，既可使用单个主从redis，也可以使用Redis Cluster；性能优异。twemproxy：高可用依赖一致性哈希，仅在缓存场景下适用，不适用存储使用；性能中等。codis：适用redis集群使用；性能通常。cerberus：适用使用Redis Cluster；在数据量较小且pipeline使用状况下性能尚可，不然性能较差。