Redis 如何搭建 Redis Cluster 集群
Redis 集群需要至少三个 master 节点，我们这里搭建三个 master 节点，并且给每个 master 再搭建一个 slave 节点，总共 6 个 redis 节点，这里用三台机器部署 6 个 redis 实例，每台机器一主一从，搭建集群的步骤如下：
开始搭建
第一步
在第一台机器的/usr/local 下创建文件夹 redis‐cluster，然后在其下面分别创建 2 个文件夾如下
mkdir ‐p /usr/local/redis‐cluster
mkdir 8001 8004第二步
把之前的 redis.conf 配置文件 copy 到 8001 下，修改如下内容：
daemonize yes
port 8001（分别对每个机器的端口号进行设置）
pidfile /var/run/redis_8001.pid # 把pid进程号写入pidfile配置的文件
dir /usr/local/redis‐cluster/8001/（指定数据文件存放位置，必须要指定不同的目录位置，不然会
丢失数据）
cluster‐enabled yes（启动集群模式）
cluster‐config‐file nodes‐8001.conf（集群节点信息文件，这里800x最好和port对应上）
cluster‐node‐timeout 10000
# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通
过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
protected‐mode no （关闭保护模式）
appendonly yes如果要设置密码需要增加如下配置：
requirepass 123456 (设置redis访问密码)
masterauth 123456 (设置集群节点间访问密码，跟上面一致)
第三步
把修改后的配置文件，copy 到 8004，修改第 2、3、4、6 项里的端口号，可以用批量替换：%s/源字符串/目的字符串/g
第四步
另外两台机器也需要做上面几步操作，第二台机器用 8002 和 8005，第三台机器用 8003 和 8006
第五步
分别启动 6 个 redis 实例，然后检查是否启动成功
/usr/local/redis‐5.0.3/src/redis‐server /usr/local/redis‐cluster/800*/redis.conf
ps ‐ef | grep redis 查看是否启动成功
第六步
用 redis‐cli 创建整个 redis 集群(redis5 以前的版本集群是依靠 ruby 脚本 redis‐trib.rb 实现)
# 下面命令里的1代表为每个创建的主服务器节点创建一个从服务器节点
# 执行这条命令需要确认三台机器之间的redis实例要能相互访问，可以先简单把所有机器防火墙关掉，如果不
关闭防火墙则需要打开redis服务端口和集群节点gossip通信端口16379(默认是在redis端口号上加1W)
# 关闭防火墙
# systemctl stop firewalld # 临时关闭防火墙
# systemctl disable firewalld # 禁止开机启动
# 注意：下面这条创建集群的命令大家不要直接复制，里面的空格编码可能有问题导致创建集群不成功
/usr/local/redis‐5.0.3/src/redis‐cli ‐a zeal ‐‐cluster create ‐‐cluster‐replicas 1 1
92.168.0.61:8001 192.168.0.62:8002 192.168.0.63:8003 192.168.0.61:8004 192.168.0.62:8005 192.168.0.63:8006第七步
验证集群：
连接任意一个客户端即可：./redis‐cli ‐c ‐h ‐p (‐a 访问服务端密码，‐c 表示集群模式，指定 ip 地址 和端口号）
如：/usr/local/redis‐5.0.3/src/redis‐cli ‐a 123456 ‐c ‐h 192.168.0.61 ‐p 800*
进行验证： cluster info（查看集群信息）、cluster nodes（查看节点列表）
进行数据操作验证
关闭集群则需要逐个进行关闭，使用命令：
/usr/local/redis‐5.0.3/src/redis‐cli ‐a zeal ‐c ‐h 192.168.0.60 ‐p 800* shutdown
gossip 通信的 10000 端口
每个节点都有一个专门用于节点间 gossip 通信的端口，就是自己提供服务的端口号+10000，比如 7001，那么用于节点间通信的就是 17001 端口。 每个节点每隔一段时间都会往另外几个节点发送 ping 消息，同时其他几点接收到 ping 消息之后返回 pong 消息。
网络抖动
真实世界的机房网络往往并不是风平浪静的，它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象，突然之间部分连接变得不可访问，然后很快又恢复正常。
为解决这种问题，Redis Cluster 提供了一种选项cluster-node-timeout，表示当某个节点持续 timeout 的时间失联时，才可以认定该节点出现故障，需要进行主从切换。如果没有这个选项，网络抖动会导致主从频繁切换 (数据的重新复制)。
集群脑裂数据丢失问题
redis 集群没有过半机制会有脑裂问题，网络分区导致脑裂后多个主节点对外提供写服务，一旦网络分区恢复，会将其中一个主节点变为从节点，这时会有大量数据丢失。
规避方法可以在 redis 配置里加上参数(这种方法不可能百分百避免数据丢失，参考集群 leader 选举机制)：
min‐replicas‐to‐write 1 //写数据成功最少同步的slave数量，这个数量可以模仿大于半数机制配置，比如
集群总共三个节点可以配置1，加上leader就是2，超过了半数
注意：这个配置在一定程度上会影响集群的可用性，比如 slave 要是少于 1 个，这个集群就算 leader 正常也不能提供服务了，需要具体场景权衡选择。
集群是否完整才能对外提供服务
当 redis.conf 的配置 cluster-require-full-coverage 为 no 时，表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群仍然可用，如果为 yes 则集群不可用。
Redis 集群为什么至少需要三个 master 节点，并且推荐节点数为奇数？
因为新 master 的选举需要大于半数的集群 master 节点同意才能选举成功，如果只有两个 master 节点，当其中一个挂了，是达不到选举新 master 的条件的。
奇数个 master 节点可以在满足选举该条件的基础上节省一个节点，比如三个 master 节点和四个 master 节点的集群相比，大家如果都挂了一个 master 节点都能选举新 master 节点，如果都挂了两个 master 节点都没法选举新 master 节点了，所以奇数的 master 节点更多的是从节省机器资源角度出发说的。
Redis 集群对批量操作命令的支持
对于类似 mset，mget 这样的多个 key 的原生批量操作命令，redis 集群只支持所有 key 落在同一 slot 的情况，如果有多个 key 一定要用 mset 命令在 redis 集群上操作，则可以在 key 的前面加上{XX}，这样参数数据分片 hash 计算的只会是大括号里的值，这样能确保不同的 key 能落到同一 slot 里去，示例如下：
mset {user1}:1:name zeal {user1}:1:age 18假设 name 和 age 计算的 hash slot 值不一样，但是这条命令在集群下执行，redis 只会用大括号里的 user1 做 hash slot 计算，所以算出来的 slot 值肯定相同，最后都能落在同一 slot。
哨兵 leader 选举流程
当一个 master 服务器被某 sentinel 视为下线状态后，该 sentinel 会与其他 sentinel 协商选出 sentinel 的 leader 进行故障转移工作。每个发现 master 服务器进入下线的 sentinel 都可以要求其他 sentinel 选自己为 sentinel 的 leader，选举是先到先得。同时每个 sentinel 每次选举都会自增配置纪元(选举周期)，每个纪元中只会选择一个 sentinel 的 leader。如果所有超过一半的 sentinel 选举某 sentinel 作为 leader。之后该 sentinel 进行故障转移操作，从存活的 slave 中选举出新的 master，这个选举过程跟集群的 master 选举很类似。
哨兵集群只有一个哨兵节点，redis 的主从也能正常运行以及选举 master，如果 master 挂了，那唯一的那个哨兵节点就是哨兵 leader 了，可以正常选举新 master。
不过为了高可用一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个 master 节点类似。
推荐阅读
•Redis 高可用架构系列（一）主从架构•Redis 高可用架构系列（二）哨兵模式•聊一聊 Redis 基本类型和使用场景•揭秘 Redis 的高性能•Redis 的持久化原理
如果觉得文章对你有帮助，可以点个赞，转载请注名出处。
评论 (0)