redis代理对比，redis架构对比，redis predixy安装和功能测试

【0】代理功能与性能对比

目前市面上主流的代理包含：predixy、twemproxy、codis、redis-cerberus四款，这四款各有各的优势，我们逐个对比进行对比分析。

如上图，我们发现 twemproxy / codis 都不支持 redis-cluster，所以我们放弃使用；（但业界 codis 用的挺多的）

性能测试报告 2017：https://blog.csdn.net/rebaic/article/details/76384028

性能测试测试报告 2020：https://github.com/netease-im/camellia/blob/master/docs/redis-proxy/performance-report-8.md

redis架构发展：https://www.cnblogs.com/crazymakercircle/p/14282108.html

【1】predixy的安装和配置

【1.1】基本介绍

predixy 是高性能的适用于 redis 集群和哨兵的代理。

predixy github 地址：https://github.com/joyieldInc/predixy

predixy 编译安装需要 C++11 版本的编译器，至少需要 CentOS 7及以上版本才能编译安装。

对于 CentOS 6或更低版本，可以直接使用在 github release 中的二进制版本。

【1.2】特性、优点

同并轻量级
支持多线程
多平台支持：Linux、OSX、BSD、Windows( Cygwin )
支持Redis Sentinel，可配置一组或者多组redis
支持Redis集群
支持redis多种类型的命令，包括blpop、brpop、brpoplpush
支持扫描命令，无论是单个redis还是多个redis实例都支持
多键命令支持：mset/msetnx/mget/del/unlink/touch/exists
支持redis的多数据库，即可以使用select命令
支持事务，当前验证于Redis Sentinel下组redis组可用
支持脚本，包括命令：script load、eval、evalsha
支持发布订阅机制，也即Pub/Sub系列命令
多数据中心支持，删除支持
扩展的AUTH命令，部分的读、写、管理权限控制机制，健空间限制机制
日志可按级别输出，记录日志被io实时记录
日志文件可以按时间、大小自动切分
大量的统计信息，包括CPU、内存、请求、响应等信息
延迟监控信息，可以看到整体延迟，分秒还原事件延迟

【2】安装

【2.1】下载解压

tar -xzf predixy-1.0.5-bin-amd64-linux.tar.gz

mv predixy-1.0.5 /data/redis/

cd /data/redis/predixy-1.0.5/conf/

【2.2】修改配置文件 cluster.conf

配置文件官方说明：https://github.com/joyieldInc/predixy/blob/master/doc/config_CN.md

predixy 支持多种架构，由于使用的是 redis cluster，只需配置 redis cluster 对应的配置文件cluster.conf 即可。

内容如下：

##ClusterServerPool {

## [Password xxx] #default no

## [MasterReadPriority [0-100]] #default 50

## [StaticSlaveReadPriority [0-100]] #default 0

## [DynamicSlaveReadPriority [0-100]] #default 0

## [RefreshInterval number[s|ms|us]] #default 1, means 1 second

## [ServerTimeout number[s|ms|us]] #default 0, server connection socket read/write timeout

## [ServerFailureLimit number] #default 10

## [ServerRetryTimeout number[s|ms|us]] #default 1

## [KeepAlive seconds] #default 0, server connection tcp keepalive

# Examples:

ClusterServerPool {

Password 123456

MasterReadPriority 60

StaticSlaveReadPriority 50

DynamicSlaveReadPriority 50

RefreshInterval 1

ServerTimeout 1

ServerFailureLimit 10

ServerRetryTimeout 1

KeepAlive 120

Servers {

+ 192.168.191.176:6381

+ 192.168.191.176:6382

+ 192.168.191.211:6383

+ 192.168.191.211:6384

+ 192.168.191.70:6385

+ 192.168.191.70:6386

}

参数说明：

MasterReadPriority，StaticSlaveReadPriority，DynamicSlaveReadPriority 三个参数和 redis 本身配置文件中的 slave-priority 没任何关系的。

如果是自动发现找到的节点，则 DynamicSlaveReadPriority 会起作用，如果是直接配置的节点，则 StaticSlaveReadPriority 会起作用。

Master/SlaveReadPriority	Master	Slave1	Slave2	Fail-over notes
60/50	all requests	0 requests	0 requests	Master dead, read requests deliver to slave until master(maybe new master) alive
60/0	all requests	0 requests	0 requests	Master dead, all requests fail
50/50	all write requests, 33.33%read requests	33.33% read requests	33.33% read requests	-
0/50	all write requests, 0 read requests	50% read requests	50% read requests	all slaves dead, all read requests fail
10/50	all write requests, 0 read requests	50% read requests	50% read requests	all slaves dead, read requests deliver to master

RefreshInterval : predixy 获取节点信息和集群 hash slot 集群信息的间隔

ServerFailureLimit ： predixy 停止路由到节点之前失败的次数

ServerTimeout ：单个命令执行的超时时间

Password: 指定连接redis实例默认的密码，不指定的情况下表示redis不需要密码

【2.3】集群自动发现

在 Servers 部分配置集群中任意一个节点即可，predixy 会自动发现整个集群的信息，即使配置的节点挂掉后，predixy 代理仍然可正常工作。

通过自动发现集群，可以减少 cluster.conf 配置文件的修改及对 predixy 的重启操作。

但 predixy 无法删除曾经自动发现的节点，如果某节点下掉，predixy 仍会看到之前的节点，虽然不影响正常使用，日志则会不断报出错误信息。需重启 predixy 解决。

【2.4】配置 predixy.conf

Name Predixy001

Bind 0.0.0.0:7617

WorkerThreads 4

ClientTimeout 300

Log /data/redis/predixy-1.0.5/predixy.log

LogRotate 1d

LogRotate 200M

Include cluster.conf

注意 Include 部分，只需包括 cluster.conf，其他的则注释掉，否则可能会影响到 predixy的使用。

基本配置文件说明：

predixy.conf，整体配置文件，会引用下面的配置文件
cluster.conf，用于Redis Cluster时，配置后端redis信息
sentinel.conf，用于Redis Sentinel时，配置后端redis信息
auth.conf，代理中心访问权限控制配置，可以定义多个验证密码，可每个密码指定读、写、管理权限，以及定义可访问的健空间
dc.conf，多数据中心支持，可以定义读写分离规则，读流量权重分配
latency.conf，延迟监控规则定义，可以指定需要监控的命令以及延时时间间隔
command.conf，自定义命令扩展，用于命令扩展，支持redis 的插件以及自定义数据处理函数等
standalone.conf，使用单击模式的redis配置

【2.5】启动predixy

　　cd /data/redis/predixy-1.0.5/bin/

　　cp predixy /data/redis/bin/ #我的redis 启动命令在这里，已添加进环境比那里

启动

看情况任选一即可

nohup predixy /data/redis/predixy-1.0.5/conf/predixy.conf &

nohup predixy /data/redis/predixy-1.0.5/conf/predixy.conf >/data/redis/predixy-1.0.5/predixy.log 2>&1 &

查看日志

tail -f /data/redis/predixy-1.0.5/predixy.log

如上，我们可以看到，由于配置文件 predixy.conf 配置的确是启动了4个进程，所以我们4个线程都就绪连接到集群所有机器了；对应构建连接池

predixy 添加环境变量

在 /etc/profile 中添加，然后在 /etc/rc.local 中设置开机启动，任选一即可

echo 'nohup predixy /data/redis/predixy-1.0.5/conf/predixy.conf &' >> /etc/rc.local

nohup predixy /usr/local/predixy-1.0.5/conf/predixy.conf > /data/redis/predixy-1.0.5/predixy.log 2>&1 &

【3】连接核验

代理连接，直接连 7617 端口就行

redis-cli -p 7617 info

可以看到 mget mset 都是没有问题的

同时代理日志信息如下：

我们通过集群的方式连接，发现key 什么的确实过去了

【4】故障转移测试

【4.1】关闭一个主库

redis-cli -h 192.168.191.70 -p 6385 -a 123456 shutdown

tail -f /data/redis/predixy-1.0.5/predixy.log

我们可以发现，b2 之前是在 6385

故障转移之后，6382 从库，经过故障转移接替 6385 成为主库;

我们继续连接代理查询：

如上图，安稳查询那么，证明故障转移是可以的；程序连接的代理，不会感知到任何东西；

同时我们查看代理日志：

看这，和炸街了一样，一直报；

这就如同【2.3】说的

　　在 Servers 部分配置集群中任意一个节点即可，predixy 会自动发现整个集群的信息，即使配置的节点挂掉后，predixy 代理仍然可正常工作。

　　通过自动发现集群，可以减少 cluster.conf 配置文件的修改及对 predixy 的重启操作。

我们连接代理，在 info 中可以发现：

　　该配置信息依然在，但其状态 CurrentIsFail：1

总结：

代理可用，集群正常故障转移，程序无感；

运维问题：日志会一直报错；forget 也没用

【4.2】下掉一个从节点

我们下一个从节点看看；

我们下掉6383吧；

redis-cli -h 192.168.191.211 -p 6383 -a 123456 shutdown

查看代理日志：

会一直报错，连不上6383，直到去掉配置文件中的这个实例，重启代理

总结：

代理可用，集群正常故障转移，程序无感；

运维问题：日志会一直报错；forget 也没用

【4.3】关闭没有从库的主库（彻底关闭一对主从）

我们关闭 6386和6383这对主从吧，看看代理这时候会发生什么；

redis-cli -h 192.168.191.211 -p 6383 -a 123456 shutdown

redis-cli -h 192.168.191.70 -p 6386 -a 123456 shutdown

我们可以看到，现在redis-cluster 已经有问题了；

我们看看代理操作是什么情况；

我们发现是不能访问的！

集群参数：

集群参数也是没一个开的；

【4.4】代理下的集群参数测试，非全slot 可用性

我们这里就不测那么多了，测一个即可，节点先启动回去

然后我们测试 cluster-allow-reads-when-down yes 这个参数吧

redis-cli -h 192.168.191.176 -p 6381 -a 123456 config set cluster-allow-reads-when-down yes

redis-cli -h 192.168.191.176 -p 6382 -a 123456 config set cluster-allow-reads-when-down yes

redis-cli -h 192.168.191.211 -p 6383 -a 123456 config set cluster-allow-reads-when-down yes

redis-cli -h 192.168.191.211 -p 6384 -a 123456 config set cluster-allow-reads-when-down yes

redis-cli -h 192.168.191.70 -p 6385 -a 123456 config set cluster-allow-reads-when-down yes

redis-cli -h 192.168.191.70 -p 6386 -a 123456 config set cluster-allow-reads-when-down yes

然后继续关闭 6383 6386 一对主从的实例

redis-cli -h 192.168.191.211 -p 6383 -a 123456 shutdown

redis-cli -h 192.168.191.70 -p 6386 -a 123456 shutdown

然后我们看看代理，是否可以如之前测试那样，对现有key 是可以访问的；

我们发现，确实是这样；直连集群也是如此；

我们上主库实例上去把开关打开；仅剩的 2个主库全都开启这个参数；

直接连redis-cluster集群上稳稳的是可以set 了；如下图：

代理上也可以了对现有存在的 slot 的操作、不存在的key 也可以创建了；如下图：

代理日志，一直报，这是常态了，如下图

【5】集群水平扩展、收缩测试

【5.1】新增主节点

（1）新增 6387 主节点

redis-cli --cluster add-node 192.168.191.82:6387 192.168.191.176:6381 -a 123456

（2）自动平衡分配slot 给新空主节点 6387

redis-cli --cluster rebalance --cluster-use-empty-masters 192.168.191.176:6381 -a 123456

（3）check 一下看看现在的集群信息

（4）检查代理日志

如下图：

我们可以发现，新加入的主节点已经被自动发现且识别出来了；

（5）使用代理操作、查阅验证

我们用代理 mset 一下

如下图，我们连接redis-cluster 查阅验证，可以发现新的 key 的get set 已经完成，并且新的key 也分配到了新加的主库 6387

如下图，我们连接代理，使用Info 查看也可以看到该主库了，由于代理开了4个线程，所以现在的连接数是4，且如果线程不挂，一般会一直保持 connections为4的；

（6）结论

没有任何问题啊，就真如redis-cluster 一样

【5.2】新增从节点

redis-cli --cluster add-node 192.168.191.82:6388 192.168.191.176:6381 --cluster-slave -a 123456

如下图：加入成功

如下图：我们可以看到，代理自动识别出来了新的，木有问题啊

要是挂掉它，我们可以发现，代理的日志依然是会一直报，这表示只要有节点加入进来了，不管你是forget 还是 del-node，也不管你是否是 cluster.conf 文件中配置的集群ip；

反正只要是集群自动发现加入过的，它都会报；如果要去掉，只能重启代理

【5.3】删除一主一从，缩容

先删除从库：

redis-cli --cluster del-node 192.168.191.176:6381 45a9ea5062479aaad68b6a9c4b5cc1942639dcb4 -a 123456

再删主库：

（1）迁移被删除主库上的 slot

把槽位平均非给其他主节点

redis-cli -a 123456 --cluster rebalance --cluster-weight

11ac5cf5004f22a55ee0afa2b221d120ad768f7d=1 f5dc23c602b57f6b09b4909d01289ff4d80220ed=1

4ba0958a0c9aa944962182673058fbc4c27952eb=1 4dfde05a131e9b8900553ef03ef41703737e449f=0

192.168.191.176:6381

（2）把节点从群集中移除，删除主节点

redis-cli -a 123456 --cluster del-node 192.168.191.176:6381 4dfde05a131e9b8900553ef03ef41703737e449f

（3）查看代理：

查看代理日志，如下图：

发现，居然没有报错（删除节点，但节点实例未关闭，所以它并没有报错，依然会连接该实例）

代理查看：

发现这2个都还在，这证明了，代理不会自动更新集群状态的删除信息，它只会自动更新新增的集群节点信息；

关闭这 6387 6388 实例；

我们发现，连不上又报错了；

【5.4】代理因为删除节点报错问题解决：重启代理

关闭：kill 进程

自动：predixy /data/redis/predixy-1.0.5/conf/predixy.conf &

重启后，报错信息没了；

登录代理：info 中的信息也更新了

6387 和 6388 实例就不见了；恢复正常;

【6】读写分离与读负载均衡的测试

Master/SlaveReadPriority	Master	Slave1	Slave2	Fail-over notes
60/50	all requests	0 requests	0 requests	Master dead, read requests deliver to slave until master(maybe new master) alive
60/0	all requests	0 requests	0 requests	Master dead, all requests fail
50/50	all write requests, 33.33%read requests	33.33% read requests	33.33% read requests	Master dead,read requests deliver to slave
0/50	all write requests, 0 read requests	50% read requests	50% read requests	all slaves dead, all read requests fail
10/50	all write requests, 0 read requests	50% read requests	50% read requests	all slaves dead, read requests deliver to master