redis发布订阅与集群

最新推荐文章于 2024-05-28 07:58:47 发布

是你吗是梦吧_

最新推荐文章于 2024-05-28 07:58:47 发布

阅读量708

点赞数 1

分类专栏： java 笔记文章标签： redis java 数据库

本文链接：https://blog.csdn.net/qq_45830289/article/details/126232453

版权

java 同时被 2 个专栏收录

46 篇文章 0 订阅

订阅专栏

笔记

26 篇文章 0 订阅

订阅专栏

本系列根据狂神说Redis写下笔记以供复习
B站狂神说Redis！：https://www.bilibili.com/video/BV1S54y1R7SB

发布订阅

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

在这里插入图片描述

命令：

subscribe channel [channel…] 订阅一个或多个频道
publish channel message 向指定频道发布消息
…

------------订阅端----------------------
127.0.0.1:6379> SUBSCRIBE sakura # 订阅sakura频道
Reading messages... (press Ctrl-C to quit) # 等待接收消息
1) "subscribe" # 订阅成功的消息
2) "sakura"
3) (integer) 1
1) "message" # 接收到来自sakura频道的消息 "hello world"
2) "sakura"
3) "hello world"
1) "message" # 接收到来自sakura频道的消息 "hello i am sakura"
2) "sakura"
3) "hello i am sakura"

--------------消息发布端-------------------
127.0.0.1:6379> PUBLISH sakura "hello world" # 发布消息到sakura频道
(integer) 1
127.0.0.1:6379> PUBLISH sakura "hello i am sakura" # 发布消息
(integer) 1

-----------------查看活跃的频道------------
127.0.0.1:6379> PUBSUB channels

在这里插入图片描述

缺点:
1.如果一个客户端订阅了频道，但自己读取消息的速度却不够快的话，那么不断积压的消息会使redis输出缓冲区的体积变得越来越大，这可能使得redis本身的速度变慢，甚至直接崩溃。
2.这和数据传输可靠性有关，如果在订阅方断线，那么他将会丢失所有在短线期间发布者发布的消息。
应用
消息订阅：公众号订阅，微博关注等等（起始更多是使用消息队列来进行实现）
多人在线聊天室。

稍微复杂的场景，我们就会使用消息中间件MQ处理。

集群环境搭建、主从复制

宝塔安装的redis的那些配置文件之类的在 /www/server/redis 中

也可以直接在宝塔中进行配置

主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（Master/Leader）,后者称为从节点（Slave/Follower），数据的复制是单向的！只能由主节点复制到从节点（主节点以写为主、从节点只能读）。

默认情况下，每台Redis服务器都是主节点，一个主节点可以有0个或者多个从节点，但每个从节点只能由一个主节点。

作用

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余的方式。
故障恢复：当主节点故障时，从节点可以暂时替代主节点提供服务，是一种服务冗余的方式
负载均衡：在主从复制的基础上，配合读写分离，由主节点进行写操作，从节点进行读操作，分担服务器的负载；尤其是在多读少写的场景下，通过多个从节点分担负载，提高并发量。

4.高可用基石：主从复制还是哨兵和集群能够实施的基础。

为什么使用集群

单台服务器难以负载大量的请求
单台服务器故障率高，系统崩坏概率大
单台服务器内存容量有限

环境配置

查看当前库的信息：info replication

在这里插入图片描述

1.复制几个conf文件分别为79 80 81
在这里插入图片描述

2.修改配置文件

2.1：改端口号

在这里插入图片描述

2.2改pid文件名字

在这里插入图片描述

2.3改日志文件名字

在这里插入图片描述

2.4：改rdb文件名字

在这里插入图片描述

然后把79 80 81 端口全部打开

接下来就要进行主从配置！

==默认情况下，每台Redis服务器都是主节点（master 老大！）；==我们一般情况下只用配置从机就好了！

认老大！一主（79）二从（80，81）

使用SLAVEOF host port就可以为从机配置主机了。

配置之后可以看到信息：
在这里插入图片描述

这样配的是暂时的，如果需要永久的话去conf里面配置！通过改写 slaveof …

使用规则

从机只能读，不能写，主机可读可写但是多用于写。

 127.0.0.1:6381> set name sakura # 从机6381写入失败
(error) READONLY You can't write against a read only replica.

127.0.0.1:6380> set name sakura # 从机6380写入失败
(error) READONLY You can't write against a read only replica.

127.0.0.1:6379> set name sakura
OK
127.0.0.1:6379> get name
"sakura"

主机挂了，从机不改变，只是集群失去了写操作的能力，主机恢复后，会连接上从机恢复原状。
从机挂了，如果不是用配置文件配置的从机，再次启动后会默认为主机，无法读取之前主机的数据。再次认大哥后又可以获取主机的所有数据。

第二条中提到，默认情况下，主机故障后，不会出现新的主机，有两种方式可以产生新的主机：

从机手动执行命令slaveof no one,这样执行以后从机会独立出来成为一个主机
使用哨兵模式（自动选举）

如果没有老大了，这个时候能不能选择出来一个老大呢？手动！

如果主机断开了连接，我们可以使用SLAVEOF no one让自己变成主机！其他的节点就可以手动连接到最新的主节点（手动）！如果这个时候老大修复了，那么就重新连接！

★哨兵模式！

为了解决以上主机挂了，需要小弟手动变老大，很麻烦也不好操作，所以哨兵模式就诞生了！

目的：自动选出一个主机（老大）

哨兵的作用：

通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

哨兵的核心配置

sentinel monitor mymaster 127.0.0.1 6379 1

数字1表示：当一个哨兵主观认为主机断开，就可以客观认为主机故障，然后开始选举新的主机。

测试一把

启动哨兵模式：

redis-sentinel xxx/sentinel.conf

在这里插入图片描述

此时哨兵监视着我们的主机6379，当我们断开主机后：

在这里插入图片描述

哨兵模式优缺点

优点：

哨兵集群，基于主从复制模式，所有主从复制的优点，它都有
主从可以切换，故障可以转移，系统的可用性更好
哨兵模式是主从模式的升级，手动到自动，更加健壮

缺点：

Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦
实现哨兵模式的配置其实是很麻烦的，里面有很多配置项

哨兵模式的全部配置

完整的哨兵模式配置文件 sentinel.conf

重要的 port sentinel monitor mymaster 127.0.0.1 6379 1

# Example sentinel.conf
 
# 哨兵sentinel实例运行的端口 默认26379
port 26379
 
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 1
 
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
 
 
 
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。  
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
 
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，
#这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
#一个是事件的类型，
#一个是事件的描述。
#如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
#通知脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh