集群,主从,哨兵sentine
- 一,Cluster集群
- cluster集群特点:
- 搭建环境
- 步骤一:所有节点安装redis并搭建完成!
- 步骤二:修改配置
- 步骤三:创建集群
- 步骤四:验证集群
- 新增节点和更改节点身份
- master宕机参考文档
- 二,主从模式
- 主从模式介绍
- 三,哨兵模式
- 哨兵模式介绍
一,Cluster集群
Cluster模式介绍:一般用的最多,包含了三种模式!!!
Cluster模式基本可以满足一般生产的需求,具备高可用性。但是当数据量过大到一台服务器存放不下的情况时,主从模式或sentinel模式就不能满足需求了,这个时候需要对存储的数据进行分片,将数据存储到多个Redis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题,将Redis的数据根据一定的规则分配到多台机器。
cluster可以说是sentinel和主从模式的结合体,通过cluster可以实现主从和master重选功能,所以如果配置两个副本三个分片的话,就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的,当数据量过大时,可以新增机器进行扩容。
使用集群,只需要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行,新增节点非常方便。
cluster集群特点:
- 多个redis节点网络互联,数据共享
- 所有的节点都是一主一从(也可以是一主多从),其中从不提供服务,仅作为备用
- 不支持同时处理多个key(如MSET/MGET),因为redis需要把key均匀分布在各个节点上,
并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为 - 支持在线增加、删除节点
- 客户端可以连接任何一个主节点进行读写
搭建环境
准备当作主的节点 | 准备当作从的 |
20.0.0.21 | 20.0.0. 26 |
20.0.0.22 | 20.0.0.27 |
20.0.0.23 | 20.0.0.28 |
步骤一:所有节点安装redis并搭建完成!
- 注意:如果您正在使用Redis 5或更高版本,这很容易完成,因为我们得到了嵌入到redis-cli,它可以用于创建新的集群、检查或重新配置现有集群,等等。
- 对于Redis版本3或4,有一个名为redis-trib.rb非常相似。你可以在srcRedis源代码发行版的目录。你需要安装redis创业板能够运行redis-trib.
步骤二:修改配置
- 配置文件更改(所有节点):
vi /etc/redis/6379.conf
70 bind 20.0.0.21 //本地ip地址
89 protected-mode no //关闭防护模式
833 cluster-enabled yes //开启集群功能
841 cluster-config-file nodes-6379.conf //当前节点存储配置文件
847 cluster-node-timeout 15000 //群集node超时时间
700 appendonly yes //开启AOF持久化功能
步骤三:创建集群
仅在一台创建就行!!
[root@localhost opt]# redis-cli --cluster create 20.0.0.21:6379 \
20.0.0.22:6379 \
20.0.0.23:6379 \
20.0.0.26:6379 \
20.0.0.27:6379 \
20.0.0.28:6379 \
--cluster-replicas 1
--replicas 1 表示主从复制比例为 1:1,即一个主节点对应一个从节点
安装过程。。。。。。。
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 20.0.0.27:6379 to 20.0.0.21:6379
Adding replica 20.0.0.28:6379 to 20.0.0.22:6379
Adding replica 20.0.0.26:6379 to 20.0.0.23:6379
M: 763aaaf4e902353da98e8479f58e3dafeec95b30 20.0.0.21:6379
slots:[0-5460] (5461 slots) master
M: f0299fef35041d6fe8388b003b56ad26ebd8ce9f 20.0.0.22:6379
slots:[5461-10922] (5462 slots) master
M: 794fbb0a856ee612ed5eabdfde3ea10d0cd96de7 20.0.0.23:6379
slots:[10923-16383] (5461 slots) master
S: c99da048b0ad841105e98765745dec931df7ee7c 20.0.0.26:6379
replicates 794fbb0a856ee612ed5eabdfde3ea10d0cd96de7
S: 97ee6a7e3411761ab54e48289c433cbe7cf57439 20.0.0.27:6379
replicates 763aaaf4e902353da98e8479f58e3dafeec95b30
S: 936f0a409d90b654124ceb02e91b34d72edd822e 20.0.0.28:6379
replicates f0299fef35041d6fe8388b003b56ad26ebd8ce9f
Can I set the above configuration? (type 'yes' to accept): yes //确定配置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 20.0.0.21:6379)
M: 763aaaf4e902353da98e8479f58e3dafeec95b30 20.0.0.21:6379
slots:[0-5460] (5461 slots) master
1 additional replica(s)
M: 794fbb0a856ee612ed5eabdfde3ea10d0cd96de7 20.0.0.23:6379
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: 97ee6a7e3411761ab54e48289c433cbe7cf57439 20.0.0.27:6379
slots: (0 slots) slave
replicates 763aaaf4e902353da98e8479f58e3dafeec95b30
S: c99da048b0ad841105e98765745dec931df7ee7c 20.0.0.26:6379
slots: (0 slots) slave
replicates 794fbb0a856ee612ed5eabdfde3ea10d0cd96de7
S: 936f0a409d90b654124ceb02e91b34d72edd822e 20.0.0.28:6379
slots: (0 slots) slave
replicates f0299fef35041d6fe8388b003b56ad26ebd8ce9f
M: f0299fef35041d6fe8388b003b56ad26ebd8ce9f 20.0.0.22:6379
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
可以看到配置:
20.0.0.21是master 哈希槽值范围是:slots:[0-5460]
20.0.0.22是master 哈希槽值范围是:slots:[5461-10922]
20.0.0.23是master 哈希槽值范围是:slots:[10923-16383]
20.0.0.26是salve 对应的主节点是23
20.0.0.27是salve 对应的主节点是21
20.0.0.28是salve 对应的主节点是22
步骤四:验证集群
[root@localhost ~]# redis-cli -c -h 20.0.0.21 //-C 是集群模式,登录集群;
20.0.0.21:6379> set name lisi
-> Redirected to slot [5798] located at 20.0.0.22:6379 //此时数据,被分配到哈希槽[5798],是在22的主节点上
OK
20.0.0.22:6379> set name1 zhangshan
-> Redirected to slot [12933] located at 20.0.0.23:6379 //此时数据,被分配到哈希槽[12933],是在23的主节点上
OK
20.0.0.23:6379> set name2 wangwu
-> Redirected to slot [742] located at 20.0.0.21:6379 //此时数据,被分配到哈希槽[742],是在21的主节点上
OK
20.0.0.21:6379>
[root@localhost ~]# redis-cli -c -h 20.0.0.27 //登录从节点服务器
20.0.0.27:6379> set age1 18
-> Redirected to slot [9008] located at 20.0.0.22:6379 //主从模式作用,写入键值,会随机自动分配到主的节点上,写的操作之会写入到主节点
OK
20.0.0.22:6379>
[root@localhost ~]# redis-cli -c -h 20.0.0.22 //登录22主节点,应该会显示刚才写入的键值!!
20.0.0.22:6379> keys *
1) "age1"
2) "name"
20.0.0.22:6379> get age1
"18"
20.0.0.22:6379>
[root@localhost ~]# redis-cli -c -h 20.0.0.28 //对应的从节点查看键值,因为会同步数据,所以可以看到所有key值
20.0.0.28:6379> keys *
1) "age1"
2) "name"
20.0.0.28:6379> get name
-> Redirected to slot [5798] located at 20.0.0.22:6379 //查看键值还是从主节点读!
"lisi"
20.0.0.22:6379>
[root@localhost ~]# redis-cli -c -h 20.0.0.28
20.0.0.28:6379> set age2 19
-> Redirected to slot [4947] located at 20.0.0.21:6379 //写入键值,会随机自动分配到主的节点上,写的操作之会写入到主节点
OK
20.0.0.21:6379>
[root@localhost ~]# redis-cli -c -h 20.0.0.26
20.0.0.26:6379> set age3 20
-> Redirected to slot [882] located at 20.0.0.21:6379 //写入键值,会随机自动分配到主的节点上,写的操作之会写入到主节点
OK
20.0.0.21:6379> get name //提取键值会从对应的主节点,提取键值
-> Redirected to slot [5798] located at 20.0.0.22:6379
"lisi"
20.0.0.22:6379> get name1
-> Redirected to slot [12933] located at 20.0.0.23:6379
"zhangshan"
20.0.0.23:6379> get name2
-> Redirected to slot [742] located at 20.0.0.21:6379
"wangwu"
- 官方文档:解释如果主节点宕机
Redis机群主从模型
为了在主节点子集失败或无法与大多数节点通信时保持可用,Redis群集使用主从模型,其中每个散列槽从1(主节点本身)到N个副本(N-1附加从节点)。
在我们的示例集群中,节点A、B、C,如果节点B失败,集群将无法继续,因为我们不再有办法在5501-11000范围内为哈希槽提供服务。
然而,当集群被创建(或在稍后的时间)时,我们向每个主节点添加一个从节点,这样最后的集群由A、B、C组成,它们是主节点,A1、B1、C1是从节点。这样,如果节点B失败,系统就能够继续运行。
节点B1复制B,B失败,集群将促进节点B1作为新的主节点,并将继续正确运行。
但是,请注意,如果节点B和B1同时失败,Redis群集将无法继续运行。
- 简单说一下原理
redis cluster在设计的时候,就考虑到了去中心化,去中间件,也就是说,集群中的每个节点都是平等的关系,都是对等的,每个节点都保存各自的数据和整个集群的状态。
每个节点都和其他所有节点连接,而且这些连接保持活跃,这样就保证了我们只需要连接集群中的任意一个节点,就可以获取到其他节点的数据。
Redis 集群没有并使用传统的一致性哈希来分配数据,而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。
redis cluster 默认分配了 16384 个slot,当我们set一个key 时,会用CRC16算法来取模得到所属的slot,然后将这个key 分到哈希槽区间的节点上,具体算法就是:CRC16(key) % 16384。
我们在测试的时候看到set 和 get 的时候,直接跳转到了创建键值的主节点上。Redis 集群会把数据存在一个 master 节点,然后在这个 master 和其对应的salve 之间进行数据同步。
当读取数据时,也根据一致性哈希算法到对应的 master 节点获取数据。
需要注意的是:必须要3个或以上的主节点,否则在创建集群时会失败,并且当存活的主节点数小于总节点数的一半时,整个集群就无法提供服务了。
新增节点和更改节点身份
集群中增加节点:
20.0.0.23:6379> cluster meet 20.0.0.29 6379
OK
//新增的节点都会是master身份!!!!
更换节点身份:
redis-cli -c -h 192.168.30.130 cluster replicate e51ab166bc0f33026887bcf8eba0dff3d5b0bf14
//后面跟node_id,更改对应节点身份。
也可以进入到redis,修改
20.0.0.23:6379>CLUSTER REPLICATE e51ab166bc0f33026887bcf8eba0dff3d5b0bf14
OK
master宕机参考文档
- 参考链接!!!!!!!
- 哨兵模式起了作用
二,主从模式
主从模式介绍
主从模式是三种模式中最简单的,在主从复制中,数据库分为两类:主数据库(master)和从数据库(slave)。
其中主从复制有如下特点:
- 主数据库可以进行读写操作,当读写操作导致数据变化时会自动将数据同步给从数据库
- 从数据库一般都是只读的,并且接收主数据库同步过来的数据
- 一个master可以拥有多个slave,但是一个slave只能对应一个master
- slave挂了不影响其他slave的读和master的读和写,重新启动后会将数据从master同步过来
- master挂了以后,不影响slave的读,但redis不再提供写服务,master重启后redis将重新对外提供写服务
- master挂了以后,不会在slave节点中重新选一个master
三,哨兵模式
哨兵模式介绍
sentinel模式是建立在主从模式的基础上
Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务:
- 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
- 提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统, 你可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。
虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel , 但实际上它只是一个运行在特殊模式下的 Redis 服务器, 你可以在启动一个普通 Redis 服务器时通过给定 –sentinel 选项来启动 Redis Sentinel 。