实验环境:
server1 172.25.254.1
server2 172.25.254.2
server3 172.25.254.3
简介
Redis Sentinel是Redis官方的高可用性解决方案。
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 。
获取Sentinel
Sentinel 程序可以在编译后的 src 文档中发现, 它是一个命名为 redis-sentinel 的程序。
用cp命令,将sentinel的配置文件复制到三台主机的 /etc/redis/下:
cp sentinel.conf /etc/redis/
启动Sentinel
redis-server /path/to/sentinel.conf --sentinel
主观下线和客观下线
-
主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。
-
客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。 (一个Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr
命令来询问对方是否认为给定的服务器已下线。)
配置
server1 2 3 中配置哨兵;
vim /etc/redis/sentinel.conf
其中做的更改为
protected-mode no 不开启保护
sentinel monitor mymaster 172.25.254.1 6379 2 监控本机的6379端口,2代表有两个投票时才可以作为master主机
sentinel down-after-milliseconds mymaster 10000 当master主机挂掉了隔10s会进行切换master
server2 和server3 ,我们都设置为server1的slave结点:
vim /etc/redis/6379.conf
测试:
在三台主机中都启动sentinel
redis-server /etc/redis/sentinel.conf --sentinel
打开后是这个样子的:
可以看到当前的master和两个slave。还有两个哨兵,server1是server2和3,2是1和3,3是1和2.
我们在server1中进入 redis-cli 命令行,连接6379 端口,执行 info 命令
就可以看到:
看到复制的信息。
我们连接26379端口,查看哨兵信息:
redis-cli -p 26379
有两个slave,三个哨兵,因为我们三个结点都打开了哨兵。
我们现在关闭server1的redis,观察server2和server3如何产生新的master,这里需要等待10s,由于我们前面的设定。
server2中:
可以看出,server2已经成为了新的master。切换成功。
而且只有一个slave 是server3。
server3中;
它时slave结点,matser是server2.
现在恢复server1的redis:
/etc/init.d/redis_6379 start
它会自动变成slave结点加入到server2的matser中。
集群
概念
Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。
Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误.
Redis 集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令.
Redis 集群的优势:
- 自动分割数据到不同的节点上。
- 整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
配置部署
我们先关闭前面开启的哨兵和redis。
server1 中
mkdir /usr/local/rediscluster 建立集群目录
[root@server1 rediscluster]# mkdir 700{1..6} 建立6个结点目录(示例)
[root@server1 rediscluster]# ls
7001 7002 7003 7004 7005 7006
在七个目录中都写一个配置文件(按序号替换):
cd 7001
vim redis.conf
port 7001
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
pidfile "/usr/local/rediscluster/7001/redis.pid"
logfile "/usr/local/rediscluster/7001/redis.log"
daemonize yes
dir "/usr/local/rediscluster/7001"
然后我们就可以打开redis了:
[root@server1 7001]# redis-server redis.conf
依次打开:
端口打开。
[root@server1 7001]# redis-cli -p 7001
127.0.0.1:7001> info
集群已经打开。
创建集群
server1 中:
用help查询集群的搭建
redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006
cluster-replicas 是创建复制结点,我们当前有8个结点,所以应该是三主三从。
以M开头的就是master结点,并分配16384个哈希槽,
我们用7001的登陆redis:
[root@server1 src]# redis-cli -c -p 7001
127.0.0.1:7001> set name westos
-> Redirected to slot [5798] located at 127.0.0.1:7002
OK
我们设置变量时就会从及群众自动重定向到7002上的5798槽上。
我们在 7003 上访问时
[root@server1 src]# redis-cli -c -p 7003
127.0.0.1:7003> get name
-> Redirected to slot [5798] located at 127.0.0.1:7002
"westos"
就会自动跳转到7002上。
7002当前是master,我们挂掉它测试高可用是否能生效:
127.0.0.1:7002> SHUTDOWN 挂掉7002
not connected>
[root@server1 ~] redis-cli --cluster info 127.0.0.1:7001
Could not connect to Redis at 127.0.0.1:7002: Connection refused
127.0.0.1:7001 (da2992a7...) -> 0 keys | 5461 slots | 1 slaves.
127.0.0.1:7004 (c1f385c9...) -> 1 keys | 5462 slots | 0 slaves.
127.0.0.1:7003 (3cb02773...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 1 keys in 3 masters.
0.00 keys per slot on average.
可见7004当前就接替7002作为了master了,它没有slave.
此时我们还可以获取到值:
因为7002 和7004 是主从关系。
但当我们在挂掉7004 时:
就获取不到值了,因为它存储在第5798个哈希槽上。他还告诉我们集群已经挂了。
这样的集群性能就不是很高了,这也是redis不被广泛应用的弊端。
这就是保存在7002上面的建值对。
我们在开启刚才挂掉的7002 7004:
就又可以看到值了。
转载:https://blog.csdn.net/thermal_life/article/details/106149834