引言
无论是为了解决redis的高可用问题、还是为了可扩展性、或者是为了维护方便,用一款redis代理都是上佳的选择。在github上有众多开源的redis代理,本文中选取三个流行的,并且各具特色的代理来和本文所要推介的predixy进行对比。
功能
特性 | 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代理,性能不行都不好意思说自己是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 -p xxx -t set,get -r 3000 -n 1000000 -d xxx
测试结果:
结果说明:
在吞吐上,predixy大幅领先于另外三款代理,当数据量达到16KB时,由于redis-benchmark本身成为瓶颈,predixy和twemproxy成绩差不多了。在延时上,codis由于语言的问题,一直都大于另外三款代理,后续测试也一样。
单线程PIPELINE SET/GET测试
测试命令:
$ redis-benchmark -p xxx -t set,get -r 3000 -n 5000000 -P 20 -d xxx
测试结果:
结果说明:
redis-benchmark一次pipeline 20个命令,瞬间qps猛增,而predixy在这轮测试中一骑绝尘,遥遥领先另外三个,在数据量大于2048之后,redis-benchmark本身成为瓶颈,才使得predixy的get请求qps降下来。另外值得注意的是,在上轮测试中落后的cerberus在本轮测试一开始表现也远好过twemproxy和codis,随着数据量的变大才逐渐掉队。
双线程PIPELINE SET/GET测试
测试命令:
$ redis-benchmark -p xxx -t set,get -r 3000 -n 10000000 -P 20 -d xxx
测试结果:
结果说明:
由于twemproxy不支持多线程,因此没有参加本轮测试,为了避免redis-benchmark成为瓶颈,在双线程中,我们没有测试单个的SET/GET,而是直接进行PIPELINE测试,测试结果和单线程的PIPELINE结果一样,predixy依然取得领先,在数据量达到2048后,redis-benchmark对predixy来说已经成为瓶颈。本轮cerberus表现也很抢眼,不过还是随着数据量的增大,表现迅速变差。
结论
同另外三款流行的redis代理相比,predixy在功能上更加全面,在性能上更是完胜,这样的一款redis代理,你喜欢吗?