环境
虚拟机:VMware 10
Linux版本:CentOS-6.5-x86_64
客户端:Xshell4
FTP:Xftp4
jdk8
redis-2.8.18
Redis集群分类:
主从复制 Replication:镜像:增删改(主<退化到单节点>)查询负载到从节点
高可用 Sentinel
分布式 twemproxy:切片
集群 Cluster
一、主从复制:从节点全量复制主节点镜像,使用单节点执行增删改操作,使用一堆从节点执行查询
(1)一个Redis服务可以有多个该服务的复制品,这个Redis服务称为Master,其他复制品称为Slaves;
只要网络连接正常,Master会一直将自己的数据更新同步给Slaves,保持主从同步,同步数据方式是异步的,不确认同步任务是否成功。
(2)只有Master可以执行写命令,Slaves只能执行读命令,从服务器执行客户端发送的读命令,比如GET、LRANGE、SMEMMBERS、HGET、ZRANGE等等,客户端可以连接Slaves执行读请求,来降低Master的读压力
(3)主从切换是手动的,使用Sentinel哨兵,实现故障自动转移Failover操作
1、主从复制创建的两种方式:
(1)配置方式:
启动时,服务器读取配置文件,并自动成为指定服务器的从服务器
slaveof <masterip> <masterport>
(2)命令方式:
redis-server --slaveof <master-ip> <master-port>,配置当前服务称为某Redis服务的Slave
# redis-server --port 6380 --slaveof 127.0.0.1 6379
SLAVEOF host port命令,将当前服务器状态从Master修改为别的服务器的Slave
redis > SLAVEOF 192.168.1.1 6379,将服务器转换为Slave
redis > SLAVEOF NO ONE ,将服务器重新恢复到Master,不会丢弃已同步数据
搭建伪分布式主从复制架构示例:
同一个节点启动三个redis实例
主:[cluster@PCS103 ~]$ redis-server --port 6380 从1:[cluster@PCS103 ~]$ redis-server --port 6381 --slaveof 127.0.0.1 6380 从2:[cluster@PCS103 ~]$ redis-server --port 6382 --slaveof 127.0.0.1 6380
(1)主节点赋值,从节点取值:
[root@PCS103 bin]# redis-cli -h PCS103 -p 6380 --raw
PCS103:6380> set k1 djfklsdk
OK
[root@PCS103 bin]# redis-cli -h PCS103 -p 6381 --raw
PCS103:6381> get k1
"djfklsdk"
(2)从节点赋值报错:
PCS103:6381> set k2 1212
(error) READONLY You can't write against a read only slave.
(3)主掉线,将6381升为主,6382修改为6381的从
PCS103:6381> SLAVEOF NO ONE
OK
PCS103:6382> SLAVEOF 127.0.0.1 6381
OK
PCS103:6382> get k1
"djfklsdk"
(4)6380重新上线,改为6381的从
[cluster@PCS103 ~]$ redis-server --port 6380 --slaveof 127.0.0.1 6381
PCS103:6380> get k1
"djfklsdk"
二、哨兵-Sentinel(3.0之前版本的做法)
主从复制下的高可用方案:
(1)Sentinel会不断检查Master和Slaves是否正常,在Master下线后自动执行Failover操作,提升一台Slave为Master,并让其他Slaves重新成为新Master的Slaves;
(2)哨兵可以监控任意多个Master和该Master下的Slaves,
(3)多个哨兵可以只监控1个Master和该Master下的Slaves,监控同一个Master的Sentinel会自动连接,组成一个分布式的Sentinel网络,互相通信并交换彼此关于被监视服务器的信息
(4)主从复制+哨兵Sentinel只解决了读性能和高可用问题,但是没有解决写性能问题
1、配置文件sentinel.conf
(1)Sentinel默认端口号为26379
(2)指定被监控Master的相关信息,Sentinel会根据Master的配置自动发现Master的Slaves
Sentinel monitor <name> <ip> <port> <quorum>
master别名 masterIP master端口 选举得票最小数
监视mymaster的主服务器,将这个主服务器判断为下线失效至少需要quorum个Sentinel同意,如果多数Sentinel同意才会执行故障转移
2、启动 Sentinel
首先启动一个Redis服务实例
其次启动哨兵:redis-sentinel sentinel.conf
举例:
搭建伪分布式主从复制架构示例,同一个节点启动三个redis实例
主:[cluster@PCS103 ~]$ redis-server --port 6380 从1:[cluster@PCS103 ~]$ redis-server --port 6381 --slaveof 127.0.0.1 6380 从2:[cluster@PCS103 ~]$ redis-server --port 6382 --slaveof 127.0.0.1 6380
配置三个哨兵:
sentinel1.conf:
port 26380
Sentinel monitor wjy 127.0.0.1 6380 2
sentinel2.conf:
port 26381
Sentinel monitor wjy 127.0.0.1 6380 2
sentinel3.conf:
port 26382
Sentinel monitor wjy 127.0.0.1 6380 2
启动三个哨兵:
[cluster@PCS103 ~]$redis-sentinel sentinel1.conf [cluster@PCS103 ~]$redis-sentinel sentinel2.conf [cluster@PCS103 ~]$redis-sentinel sentinel3.conf
3、监控过程
当一个sentinel认为被监视的服务器已经下线时,它会向网络中的其他Sentinel进行确认,判断该服务器是否真的已经下线
如果下线的服务器为主服务器,那么sentinel网络将对下线主服务器进行自动故障转移,通过将下线主服务器的某个从服务器提升为新的主服务器,并让其从服务器转为复制新的主服务器,以此来让系统重新回到上线的状态