Redis笔记——发布订阅及主从复制

最新推荐文章于 2022-12-06 01:10:17 发布

小李小刘爱编程

最新推荐文章于 2022-12-06 01:10:17 发布

阅读量229

点赞数

分类专栏：中间件文章标签： redis 数据库 database

本文链接：https://blog.csdn.net/qq_49182770/article/details/122779855

版权

中间件专栏收录该内容

6 篇文章 0 订阅

订阅专栏

Redis发布订阅

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。微信、微博、关注系统！ Redis 客户端可以订阅任意数量的频道。订阅/发布消息图：第一个：消息发送者，第二个：频道第三个：消息订阅者！

下图展示了频道 channel1 ，以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

在这里插入图片描述

当有新消息通过 PUBLISH 命令发送给频道 channel1 时，这个消息就会被发送给订阅它的三个客户端：

在这里插入图片描述

命令

PSUBSCRIBE pattern [pattern..] 订阅一个或多个符合给定模式的频道。
PUNSUBSCRIBE pattern [pattern..] 退订一个或多个符合给定模式的频道。
PUBSUB subcommand [argument[argument]] 查看订阅与发布系统状态。
PUBLISH channel message 向指定频道发布消息
SUBSCRIBE channel [channel..] 订阅给定的一个或多个频道。
UNSUBSCRIBE channel [channel..] 退订一个或多个频道

代码示例

------------订阅端----------------------
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
"sakura"

原理

Redis是使用C实现的，通过分析 Redis 源码里的 pubsub.c 文件，了解发布和订阅机制的底层实现，籍此加深对 Redis 的理解。

Redis 通过 PUBLISH 、SUBSCRIBE 和 PSUBSCRIBE 等命令实现发布和订阅功能。

每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构，结构的 pubsub_channels 属性是一个字典，这个字典就用于保存订阅频道的信息，其中，字典的键为正在被订阅的频道，而字典的值则是一个链表，链表中保存了所有订阅这个频道的客户端。

在这里插入图片描述

客户端订阅，就被链接到对应频道的链表的尾部，退订则就是将客户端节点从链表中移除。

缺点

如果一个客户端订阅了频道，但自己读取消息的速度却不够快的话，那么不断积压的消息会使redis输出缓冲区的体积变得越来越大，这可能使得redis本身的速度变慢，甚至直接崩溃。
这和数据传输可靠性有关，如果在订阅方断线，那么他将会丢失所有在短线期间发布者发布的消息。

应用

消息订阅：公众号订阅，微博关注等等（起始更多是使用消息队列来进行实现）
多人在线聊天室。

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

Redis主从复制

概念

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

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

作用

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

为什么使用集群

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的（宕机），原因如下：

1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；

2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"。

对于这种场景，我们可以使如下这种架构：
在这里插入图片描述

主从复制，读写分离！ 80% 的情况下都是在进行读操作！减缓服务器的压力！架构中经常使用！一主二从！

只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis！

总结

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

环境配置

只配置从库，不用配置主库！

127.0.0.1:6379> info replication
# Replication
role:master # 角色
connected_slaves:0 # 从机数量
master_replid:3b54deef5b7b7b7f7dd8acefa23be48879b4fcff
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

复制3个配置文件，然后修改对应的信息

端口
pid名字
log文件名
dump.rdb名字

启动单机多服务集群：
在这里插入图片描述

一主二从配置

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

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

使用SLAVEOF host port就可以为从机配置主机了。
在这里插入图片描述

说明

SLAVEOF host 6379 找谁当自己的老大！
role:slave # 当前角色是从机
master_host:127.0.0.1 # 可以的看到主机的信息

然后主机上也能看到从机的状态：

在这里插入图片描述

说明

connected_slaves:1 # 多了从机的配置
slave0:ip=127.0.0.1,port=6380,state=online,offset=42,lag=1 # 多了从机的配置

真实的从主配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，暂时的！

使用规则

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

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"

2.当主机断电宕机后，默认情况下从机的角色不会发生变化，集群中只是失去了写操作，当主机恢复以后，又会连接上从机恢复原状。

3.当从机断电宕机后，若不是使用配置文件配置的从机，再次启动后作为主机是无法获取之前主机的数据的，若此时重新配置称为从机，又可以获取到主机的所有数据。这里就要提到一个同步原理。

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

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

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

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

复制原理

Slave 启动成功连接到 master 后会发送一个sync同步命令

Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。

全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：Master 继续将新的所有收集到的修改命令依次传给slave，完成同步

但是只要是重新连接master，一次完全同步（全量复制）将被自动执行！我们的数据一定可以在从机中看到！

小李小刘爱编程

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis笔记——发布订阅及主从复制

Redis发布订阅Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。微信、微博、关注系统！ Redis 客户端可以订阅任意数量的频道。订阅/发布消息图：第一个：消息发送者，第二个：频道第三个：消息订阅者！下图展示了频道 channel1 ，以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：当有新消息通过 PUBLISH 命令发送给频道 channel1 时，这个消息就会被发
复制链接

扫一扫