【1】gcc 4.9+安装
sudo yum install centos-release-scl
sudo yum install devtoolset-7-gcc*
scl enable devtoolset-7 bash
which gcc
gcc --version
【2】redis-cluster-proxy 介绍与安装
功能介绍：
Redis的集群代理适用redis-cluster集群。Redis 能够在集群模式下运行，其中一组 Redis 实例将负责故障转移和分区。
这种特殊模式需要使用理解集群协议的特殊客户端：通过使用这个代理来代替集群，集群被抽象出来，并且您可以与组成 Redis 集群的一组实例进行对话，就像它们是单个实例一样。
Redis Cluster Proxy 是多线程的，默认情况下，它当前使用多路复用通信模型，因此每个线程都有自己的集群连接，该连接与属于该线程本身的所有客户端共享。
无论如何，在某些特殊情况下（即。MULTI事务或阻塞命令），多路复用被禁用，客户端将拥有自己的集群连接。
通过这种方式，客户端只需发送诸如 GET 和 SET 之类的简单命令就不需要到 Redis 集群的私有连接集。
因此，这些是 Redis Cluster Proxy 的主要功能：
- 路由：每个查询都会自动路由到集群的正确节点
- 多线程
- 支持多路复用和专用连接模型
- 即使在多路复用上下文中也能保证查询执行和回复顺序
ASK|MOVED错误后集群配置的自动更新：当这些类型的错误发生在回复中时，代理通过获取集群的更新配置并重新映射所有插槽来自动更新集群的内部表示。更新完成后将重新执行所有查询，因此，从客户端的角度来看，一切正常（客户端不会收到 ASK|MOVED 错误：他们将直接收到预期的回复集群配置已更新）。
- 跨槽/跨节点查询：支持许多涉及属于不同槽（甚至不同集群节点）的多个键的命令。这些命令会将查询拆分为多个查询，这些查询将路由到不同的插槽/节点。这些命令的回复处理是特定于命令的。某些命令，例如MGET，会将所有回复合并为一个回复。其他命令，例如MSET或DEL将对所有回复的结果求和。由于这些查询实际上破坏了命令的原子性，因此它们的用法是可选的（默认情况下禁用）。请参阅下文了解更多信息。
- 一些没有特定节点/槽的命令，例如DBSIZE被传递到所有节点，并且回复将被映射减少，以便给出所有回复中包含的所有值的总和。
PROXY可用于执行某些特定于代理的操作的附加命令。
下载安装：
官网：https://github.com/RedisLabs/redis-cluster-proxy
解压安装：
unzip redis-cluster-proxy-unstable.zip
cd redis-cluster-proxy-unstable
make PREFIX=/data/redis/ install
mkdir /data/redis/redis-cluster-proxy
cp proxy.conf /data/redis/redis-cluster-proxy/proxy.conf
注意：此前我们已经安装配置好一个 3主3从的集群
配置文件：
cat <<eof >/data/redis/redis-cluster-proxy/proxy.conf # ./redis-cluster-proxy -c /path/to/proxy.conf # cluster 127.0.0.1:7000 cluster 192.168.191.176:6381 cluster 192.168.191.176:6382 cluster 192.168.191.211:6383 cluster 192.168.191.211:6384 cluster 192.168.191.70:6385 cluster 192.168.191.70:6386 ################################### MAIN ###################################### port 7777 # bind 127.0.0.1 unixsocket /data/redis/redis-cluster-proxy/proxy.socket threads 8 tcpkeepalive 300 connections-pool-size 10 connections-pool-min-size 10 daemonize yes pidfile /data/redis/redis-cluster-proxy/proxy.pid logfile /data/redis/redis-cluster-proxy/proxy.log enable-cross-slot yes #max-clients 1000 auth 123456 # Authentication username (supported by Redis >= 6.0) # auth-user myuser ################################# LOGGING ##################################### # Log level: can be debug, info, success, warning o error. log-level error # Dump queries received from clients in the log (log-level debug required) # dump-queries no # Dump buffer in the log (log-level debug required) # dump-buffer no # Dump requests' queues (requests to send to cluster, request pending, ...) # in the log (log-level debug required) # dump-queues no eof
启动
cd /data/redis/bin
redis-cluster-proxy -c /data/redis/redis-cluster-proxy/proxy.conf
【3】连接核验
redis-cli -c 192.168.191.176 -p 7777 -a 123456
如下图：发现的确是写到不同的节点上去了
【4】故障转移
【4.0】查看集群状态
redis-cli --cluster check 192.168.191.176:6381 -a 123456
我们可以看到，6381 6386 6385 是主库
【4.1】集群挂一个主库的影响
现在集群6个节点状态是好的
我们关闭掉 6381 实例试试；
redis-cli -h 192.168.191.176 -p 6381 -a 123456 shutdown
如下图：从代理连接，我们可以看到 6381 的节点连接已断开
如下图：从redis-cluster 角度来看，已经很好的故障转移了
我们看看这个是否还可以用：
发现有关存储在 6381 实例上的 key 都不可用；
如下图：错误日志：在查询 存储在 6381 的 key 的时候，报错 不能链接到 6381 redis实例，我们 proxy cluster update 的时候，直接就报错 失败获取集群配置了；
但我们直连集群是可以正常操作的：
结论：代理程序并没有挂，但是无法做任何操作；
只有当配置文件中的所有配置 IP 实例 都正常后，重启代理，才可以正常运行；
【4.2】集群挂一个从库的影响
现在集群6个节点状态是好的
那我们现在关闭 6382 试试；
redis-cli -h 192.168.191.176 -p 6382 -a 123456 shutdown
关闭后：
我们连接代理=》查看集群状态：
集群状态是没有问题的，且下面的nodes中，也显示所有主节点都有一个从库（但实际上从库挂了，对应的主库所在节点的 replicas 应该为0才对，但并没有）；
但我们更新一下集群状态；
如下图：代理状态直接变成失败、中断 broken；且不可用，任何操作都是这种报错
虽然这种情任何操作都会报错，但是代理并没有关闭，可以登录，只是无法做任何操作，如下图
日志信息：
这个时候，把 6382再启动，也自动加入集群了；但是代理并没有恢复，也无法在现有情况 proxy cluster update 更新回集群连接状态信息
必须要重启代理才可以：
【结论】
（1）集群某个机器down后，如果不更新代理连接集群，还是可以正常使用的；
如果down的是主库，则通过代理无法访问该主库节点
如果down的是从库，则不影响
（2）代理在启动重新、拉取集群连接信息时，如果在配置文件中配置的任意实例无法连接，则整个代理不可用；
（3）如果redis 集群没有启动成功，redis-cluster-proxy 启动是无法连接到 redis 节点的；
如果出现 redis 集群启动 Waiting for the cluster to join 的情况，redis-cluster-proxy 可以启动成功，但是无法操作。
（4）无法支持故障转移