Redis（八）------发布订阅、主从复制

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，一次完全同步（全量复制）将被自动执行