介绍
redis作为一款优秀的NoSQL代表软件，正变得越来越流行，虽然Redis很容易就可以启动并使用，但是要想在线上用好它却也并非易事。redis的高可用和可扩展无论是自带的Redis Sentinel还是Redis Cluster都要求客户端进行额外的支持，而目前基本上没有合适的客户端能够做这些事情，实际上客户端来做这些事情也并不合适，它会让维护变得特别困难。因此在客户端和redis服务端之间加一层代理成了一种理想的方案，代理屏蔽后端Redis实现细节向客户端提供redis服务，可以完美的解决Redis的高可用和扩展性问题，同时代理的引入也使得Redis维护变得更加简单。在本文所要介绍的代理predixy之前，已经有几款流行的redis代理，它们各具特色。接下来，我们就来比较以下代理：
| 代理 | 简介 |
|---|---|
| predixy | 高性能全特征redis代理，支持Redis Sentinel和Redis Cluster |
| twemproxy | 快速、轻量级memcached和redis代理 |
| codis | redis集群代理解决方案 |
| redis-cerberus | Redis Cluster代理 |
详细功能对比
| 特性 | predixy | twemproxy | codis | redis-cerberus |
|---|---|---|---|---|
| 高可用 | Redis Sentinel或Redis Cluster | 一致性哈希 | Redis Sentinel | Redis Cluster |
| 可扩展 | Key哈希分布或Redis Cluster | Key哈希分布 | Key哈希分布 | Redis Cluster |
| 开发语言 | C++ | C | GO | C++ |
| 多线程 | 是 | 否 | 是 | 是 |
| 事务 | Redis Sentinel模式单Redis组下支持 | 不支持 | 不支持 | 不支持 |
| BLPOP/BRPOP/BLPOPRPUSH | 支持 | 不支持 | 不支持 | 支持 |
| Pub/Sub | 支持 | 不支持 | 不支持 | 支持 |
| Script | 支持load | 不支持 | 不支持 | 不支持 |
| Scan | 支持 | 不支持 | 不支持 | 不支持 |
| Select DB | 支持 | 不支持 | 支持 | Redis Cluster只有一个DB |
| Auth | 支持定义多个密码，给予不同读写及管理权限和Key访问空间 | 不支持 | 同redis | 不支持 |
| 读从节点 | 支持，可定义丰富规则读指定的从节点 | 不支持 | 支持，简单规则 | 支持，简单规则 |
| 多机房支持 | 支持，可定义丰富规则调度流量 | 不支持 | 有限支持 | 有限支持 |
| 统计信息 | 丰富 | 丰富 | 丰富 | 简单 |
简单来说，predixy既支持Redis Sentinel也支持Redis Cluster
- 后端为Redis Sentinel监控的一组Redis，功能完全等同于原始Redis
- 后端为Redis Sentinel监控的多组Redis，则有部分功能受限
- 后端为Redis Cluster，功能完全等同于Redis Cluster
性能
作为redis代理，高性能是硬性要求，为了测试上面四款代理的性能接下来我们就来做个简单的评测，测试平台及各代理具体的版本信息如下：
| 名称 | 内容 |
|---|---|
| CPU | AMD Ryzen 7 1700X Eight-Core Processor 3.775GHz |
| 内存 | 16GB DDR4 3000 |
| 系统 | x86_64 GNU/Linux 4.10.0-27-generic #30~16.04.2-Ubuntu |
| predixy | 版本1.0.1，源码默认参数编译 |
| twemproxy | 版本0.4.1，源码默认参数编译 |
| codis | 二进制发布版本codis3.2.0-go1.8.1-linux.tar.gz |
| cerberus | github迁出8d68a5d源码默认参数编译 |
redis-server、各代理、redis-benchmark均在这一台机器上运行。
redis部署：
| 代理 | redis后端部署 |
|---|---|
| predixy | redis cluster模式部署三个redis主节点, slots平分 |
| twemproxy | 三个redis主节点，采用crc16哈希，modula分布 |
| codis | 三个redis主节点，slots平分 |
| cerberus | redis cluster模式部署三个redis主节点, slots平分 |
以下测试的结果中，横坐标为数据大小、纵坐标为qps或者毫秒。
单线程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使用情况下性能尚可，否则性能较差。
