Redis(八)------发布订阅、主从复制
13、发布订阅
- Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。
- Redis客户端可以订阅任意数量的频道
- 频道
channel1
,订阅这个频道的三个客户端client2
、client5
、client1
之间的关系,如下图:
- 当有新消息通过
PUBLISH
命令发送给频道channel1
时,这个消息就会被发送给订阅它的三个客户端,流程如下图:
13.1 基础命令
命令 | 描述 |
---|---|
PSUBSCRIBE pattern1 pattern2… | 订阅一个/多个符合给定模式的频道 |
PUNSUBSCRIBE pattern1 pattern2… | 退订一个/多个符合给定模式的频道 |
PUBSUB subcommand | 查看订阅与发布系统状态 |
PUBLISH channel(消息发送者) message(发布信息) | 向指定频道发布消息 |
SUBSCRIBE channel1(频道名称) channel2… | 订阅给定的一个/多个频道 |
UNSUBSCRIBE channel1 channel2… | 退订一个/多个频道 |
- 实例
------------订阅端 ----------------------
# 订阅zzz频道
127.0.0.1:6379> SUBSCRIBE zzz
# 等待接收消息
Reading messages... (press Ctrl-C to quit)
# 订阅成功的消息
1) "subscribe"
2) "zzz"
3) (integer) 1
# 接收到来自zzz频道的消息 "hello world"
# 消息
1) "message"
# 来自哪个频道
2) "zzz"
# 消息具体内容
3) "hello world"
# 接收到来自zzz频道的消息 "hello i am zzz"
1) "message"
2) "zzz"
3) "hello i am zzz"
--------------消息发布端 -------------------
# 发布消息到zzz频道
127.0.0.1:6379> PUBLISH zzz "hello world"
(integer) 1
# 发布消息
127.0.0.1:6379> PUBLISH zzz "hello i am zzz"
(integer) 1
-----------------查看活跃的频道 ------------
127.0.0.1:6379> PUBSUB channels
1) "zzz"
13.2 原理
-
每个Redis服务器进程都维持着一个表示服务器状态的
redis.h/redisServer
结构,结构的pubsub_channels
属性是一个字典,这个字典就用于保存订阅频道的信息,其中,字典的建是正在被订阅的频道,而字典的值是一个链表,链表中保存了所有订阅这个频道的客户端
-
客户端订阅,就被连接到对应频道的链表的尾部,退订就是将客户端节点从链接中移除
13.3 缺点
- 如果一个客户端订阅了频道,但自己读取消息的速度却不够快的话,那么不断积压的消息会使redis输出缓冲区的体积变得越来越大,这可能使得redis本身的速度变慢,甚至直接崩溃
- 这和数据传输的可靠性有关,如果订阅方断线,那么他将会丢失所有在断线期间发布者发布的消息
13.4 具体应用场景
- 消息订阅:公众号订阅,微博关注等
- 多人在线聊天室
- 其他复杂场景,使用消息中间件MQ去实现
14、主从复制
14.1 基本概念
- 主从复制,是指将一台Redis服务器的数据,复制到其他Redis服务器。前者称为主节点(Master/Leader),后者称为从节点(Slave/Follower)
- 数据的复制是单向的,只能从主节点复制到从节点(主节点以写为主,从节点以读为主)
- 默认情况下,每台Redis服务器都是主节点,一个主节点可以有0个或多个从节点,但每个从节点只能有一个直接点
14.2 作用
- 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式
- 故障恢复:当主节点故障时,从节点可以暂时代替主节点提供服务,是一种服务冗余的方式
- 负载均衡:在主从复制的基础上,配合读写分离,由主节点进行写操作,从节点进行读操作,分担服务器的负载,尤其是在读多写少的场景下,通过多个从节点分担负载,提高并发量
- 高可用基石:主从复制是
哨兵
和集群
能够实施的基础
14.3 为什么使用集群
-
一般来说,Redis运用于工程项目中,只使用一台Redis是不行的,原因如下:
- 从结构上讲,单个Redis服务器会发生单点故障,并且一台服务器需要处理的所有请求负载,压力较大
- 从容量上讲,单个Redis服务器内存容量有限,就算一台Redis服务器内存容量为256G,也不能将所有内存用作Redis存储内存。通常情况下,单台Redis最大使用内存不超过20G
-
单台服务器难以负载大量请求
-
单台服务器故障率高,系统崩坏概率大
-
单台服务器内存容量有限
14.4 环境配置
-
配置环境时,只配置从库,不用配置主库
-
Redis配置文件中,有一个
replication
模块 -
查看当前库的信息:
info replication
127.0.0.1:6379> info replication
# Replication
# 角色
role:master
# 从机数量 0
connected_slaves:0
master_replid:ad05a88a5404924d3e4c7487b32e0019f5d6fb7b
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
- 需要启动多个服务,就需要配置多个配置文件,每个对应配置文件应该修改一下信息:
- 端口号
- pid文件名:记录了进程的ID,文件带锁,可以防止程序多次启动:
redis_6379.pid
- 日志文件名:明确日志文件位置:
logfile“6379.log”
- rdb文件名:持久化文件的位置:
dump6379.rdb
14.5 一主二从配置
-
远程服务器需要开启安全组和防火墙
-
默认情况下,每台Redis服务器都是主节点,著需要配置从机即可,主(6379),从(6380,6381)
-
同时启动三个redis-server,可以通过进程信息查看:
ps -ef|grep redis
-
使用
SLAVEOF host port
为从机配置主机,host:主机IP,port:主机端口号 -
127.0.0.1:6380配置
127.0.0.1:6380> slaveof localhost 6379
OK
127.0.0.1:6380> info replication
# Replication
# 角色变为slave
role:slave
master_host:localhost
# 主机端口号
master_port:6379
master_link_status:up
- 主机上可以查阅从机状态
127.0.0.1:6379> info replication
# Replication
role:master
# 2个从机
connected_slaves:2
# 第一台从机
slave0:ip=127.0.0.1,port=6380,state=online,offset=504,lag=1
# 第二台从机
slave1:ip=127.0.0.1,port=6381,state=online,offset=504,lag=0
- 这种方式是用命令搭建的,暂时的,从机断电即失;真实开发中应该在从机的配置文件中进行配置,是永久的
replicaof 主机IP 主机端口号
masterauth 主机密码
14.6 使用规则
- 从机只能读,不能写;主机可读可写,但多用于写
- 主机断电宕机后,默认情况下从机的角色不会发生变化,只是集群中失去了写操作;主机恢复后,会连接上从机恢复原状
- 从机断点宕机后,如果不是使用配置文件配置的从机,再次启动后作为主机,是无法获取之前主机的数据的;此时重新配置成为从机,可以获取主机所有数据
- 主机故障后,有两种方式可以产生新的主机:
- 从机手动执行命令
slaveof no one
,执行完毕,从机独立成为一个主机,其他从机成为新主机的从机 - 使用哨兵模式(自动选举)
- 从机手动执行命令
14.7 复制原理
- Slave启动成功连接到Master后会发送一个sync同步命令
- Master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集的命令
- 在后台进程执行完毕后,Master将传送整个数据文件到Slave,并完成一次完全同步
- 全量复制:Slave服务在接收到数据库文件数据后,将其存盘并加载到内存中
- 增量复制:Master继续将新收集到的所有修改命令,依次传给Slave,完成同步
- 只要重新连接Master,一次完全同步(全量复制)将被自动执行