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

Redis发布订阅（pub/sub）是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。Redis客户端可以订阅任意数量的频道频道channel1，订阅这个频道的三个客户端client2、client5、client1之间的关系，如下图：

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

实例

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

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

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

如果一个客户端订阅了频道，但自己读取消息的速度却不够快的话，那么不断积压的消息会使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

单台服务器难以负载大量请求

单台服务器故障率高，系统崩坏概率大

单台服务器内存容量有限

配置环境时，只配置从库，不用配置主库

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 主机密码

从机只能读，不能写；主机可读可写，但多用于写主机断电宕机后，默认情况下从机的角色不会发生变化，只是集群中失去了写操作；主机恢复后，会连接上从机恢复原状从机断点宕机后，如果不是使用配置文件配置的从机，再次启动后作为主机，是无法获取之前主机的数据的；此时重新配置成为从机，可以获取主机所有数据主机故障后，有两种方式可以产生新的主机：

从机手动执行命令slaveof no one，执行完毕，从机独立成为一个主机，其他从机成为新主机的从机使用哨兵模式（自动选举） 14.7 复制原理

Slave启动成功连接到Master后会发送一个sync同步命令Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集的命令在后台进程执行完毕后，Master将传送整个数据文件到Slave，并完成一次完全同步全量复制：Slave服务在接收到数据库文件数据后，将其存盘并加载到内存中增量复制：Master继续将新收集到的所有修改命令，依次传给Slave，完成同步只要重新连接Master，一次完全同步（全量复制）将被自动执行