redis主从集群哨兵

Posted 2020-10-31 xuwc

redis的主从、集群、哨兵

 

参考：

 https://blog.csdn.net/robertohuang/article/details/70833231

 

 

 

1.为什么要有集群 
由于Redis主从复制架构每个数据库都要保存整个集群中的所有数据,容易形成木桶效应，所以Redis3.0之后的版本添加特性就是集群(Cluster)

2.Redis集群架构说明 

架构细节: 
(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽. 
(2)节点的fail是通过集群中超过半数的master节点检测失效时才生效. 
(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可 
(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->key

3.Redis Cluster环境搭建 
3.1 分别修改配置文件,将端口分别设置为:6379、6380、6381,同时要设置pidfile文件为不同的路径。并且允许集群模式,修改集群配置文件指向地址,并且开启远程访问

修改配置文件
# vim /opt/redis/6379/6379.conf

# 开启守护进程模式
daemonize yes

# 修改启动端口为6379
port 6379

# 修改pidfile指向路径
pidfile /opt/redis/6379/redis_6379.pid

# 开启允许集群 
cluster-enabled yes

# 修改集群配置文件指向路径
cluster-config-file nodes-6379.conf

# 注释一下内容开启远程访问
# bind 127.0.0.1

# 关闭保护模式
protected-mode no

以此类推,修改端口6380及6381配置。

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25

3.2 分别启动redis实例

# cd /opt/redis/redis-3.2.8/bin
# ./redis-server /opt/redis/6379/6379.conf 
# ./redis-server /opt/redis/6380/6380.conf     
# ./redis-server /opt/redis/6381/6381.conf 

• 1
• 2
• 3
• 4

3.3 查看redis状态 

说明redis已经是以集群方式启动了,但是redis之间关系还没确定下来

3.4 因为redis-trib.rb是由ruby语言编写的所以需要安装ruby环境

安装ruby环境
# yum -y install zlib ruby rubygems

自行上传redis-3.2.1.gem然后安装
# gem install -l redis-3.2.1.gem

• 1
• 2
• 3
• 4
• 5

3.5 建立集群Redis关系

首先，进入redis的安装包路径下
# cd /opt/redis/redis-3.2.8/src

执行命令：
# ./redis-trib.rb create --replicas 0 192.168.29.128:6379 192.168.29.128:6380 192.168.29.128:6381

说明:--replicas 0：指定了从数据的数量为0
注意：这里不能使用127.0.0.1，否则在Jedis客户端使用时无法连接到！

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

3.6 如果出现如下异常

/usr/local/share/gems/gems/redis-3.2.1/lib/redis/client.rb:113:in `call‘: ERR Slot 0 is already busy (Redis::CommandError)
        from /usr/local/share/gems/gems/redis-3.2.1/lib/redis.rb:2556:in `block in method_missing‘
        from /usr/local/share/gems/gems/redis-3.2.1/lib/redis.rb:37:in `block in synchronize‘
        from /usr/share/ruby/monitor.rb:211:in `mon_synchronize‘
        from /usr/local/share/gems/gems/redis-3.2.1/lib/redis.rb:37:in `synchronize‘
        from /usr/local/share/gems/gems/redis-3.2.1/lib/redis.rb:2555:in `method_missing‘
        from ./redis-trib.rb:212:in `flush_node_config‘
        from ./redis-trib.rb:776:in `block in flush_nodes_config‘
        from ./redis-trib.rb:775:in `each‘
        from ./redis-trib.rb:775:in `flush_nodes_config‘
        from ./redis-trib.rb:1296:in `create_cluster_cmd‘
        from ./redis-trib.rb:1701:in `<main>‘

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

经检查，这是由于上一次配置集群失败时留下的配置信息导致的。 只要把redis.conf中定义的 cluster-config-file 所在的文件删除，重新启动redis-server及运行redis-trib即可。

3.7 建立集群Redis关系正常执行响应如下

>>> Creating cluster
>>> Performing hash slots allocation on 3 nodes...
Using 3 masters:
192.168.29.128:6379
192.168.29.128:6380
192.168.29.128:6381
M: d5d0951bb185a67a44d29dd2142170dbce84d977 192.168.29.128:6379
   slots:0-5460 (5461 slots) master
M: e41fe58ef571836d891656b482307628b3f7ab35 192.168.29.128:6380
   slots:5461-10922 (5462 slots) master
M: ddbc810661f81500059e0b22b1550713a0e3766d 192.168.29.128:6381
   slots:10923-16383 (5461 slots) master
Can I set the above configuration? (type ‘yes‘ to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join...
>>> Performing Cluster Check (using node 192.168.29.128:6379)
M: d5d0951bb185a67a44d29dd2142170dbce84d977 192.168.29.128:6379
   slots:0-5460 (5461 slots) master
   0 additional replica(s)
M: ddbc810661f81500059e0b22b1550713a0e3766d 192.168.29.128:6381
   slots:10923-16383 (5461 slots) master
   0 additional replica(s)
M: e41fe58ef571836d891656b482307628b3f7ab35 192.168.29.128:6380
   slots:5461-10922 (5462 slots) master
   0 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
成功

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32

3.8 查看集群节点信息 

3.9 测试 
3.9.1 测试插入数据 

因为abc的hash槽信息是在6380上，现在使用redis-cli连接的6379，无法完成set操作，需要客户端跟踪重定向。使用redis-cli -c

3.9.2 重新测试插入数据 

4. 插槽的概念及插槽分配 
整个Redis提供了16384个插槽，也就是说集群中的每个节点分得的插槽数总和为16384。./redis-trib.rb 脚本实现了是将16384个插槽平均分配给了N个节点。当我们执行set abc 123命令时,redis是如何将数据保存到集群中的呢?执行步骤：

i.接收命令set abc 123
ii.通过key(abc)计算出插槽值,然后根据插槽值找到对应的节点。abc的插槽值为:7638
iii.重定向到该节点执行命令

• 1
• 2
• 3

注意：如果插槽数有部分是没有指定到节点的，那么这部分插槽所对应的key将不能使用。

5.新增集群节点 
5.1 再开启一个实例的端口为6382 配置同上 

5.2 执行脚本建立6382节点与集群的关系 

5.3 查看集群状态,发现新增的节点没有插槽 

5.4 给6382节点分配插槽 

5.5 查看集群节点状态 

6.删除集群节点 
想要删除集群节点中的某一个节点，需要严格执行2步:

6.1.将这个节点上的所有插槽转移到其他节点上 
6.1.1执行脚本：./redis-trib.rb reshard 192.168.29.128:6382

6.1.2选择需要转移的插槽的数量，因为6382有100个，所以转移100个

6.1.3输入转移的节点的id，我们转移到6379节点

6.1.4输入插槽来源id，也就是6382的id

6.1.5输入done，开始转移 

6.1.6查看集群节点信息，可以看到6380节点已经没有插槽了 

6.2.删除节点 
6.2.1 删除节点 

6.2.2 查看集群节点信息 

7. Redis Cluster高可用 
7.1 假设集群中某一节点宕机 测试数据写入操作 

我们尝试执行set命令，结果发现无法执，行集群不可用了？？ 这集群也太弱了吧？？

7.2 集群中的主从复制架构 

7.3 本教程不详细介绍集群中主从复制架构的具体安装,只提一下过程

7.3.1 为每个集群节点添加Slave,形成主从复制架构,主从复制架构可参考:主从复制架构,搭建结构如下所示

6379(Master)     6479(Slave of 6379)     6579(Slave of 6379)
6380(Master)     6480(Slave of 6380)     6580(Slave of 6380)
6381(Master)     6481(Slave of 6381)     6581(Slave of 6381)

• 1
• 2
• 3

7.3.2 为每个主从复制架构添加哨兵集群,哨兵模式集群可参考:哨兵模式集群

7.3.3 创建集群 使用如下命令

./redis-trib.rb create --replicas 2 192.168.29.128:6379 192.168.29.128:6380 192.168.29.128:6381 192.168.29.128:6479 192.168.29.128:6480 192.168.29.128:6481 192.168.29.128:6579 192.168.29.128:6580 192.168.29.128:6581 

• 1

7.4.4 自行测试高可用Cluster环境

注意在集群环境中: 
多键的命令操作(如MGET、MSET)，如果每个键都位于同一个节点，则可以正常支持，否则会提示错误。

集群中的节点只能使用0号数据库，如果执行SELECT切换数据库会提示错误。