Redis-05-Redis中的消息订阅发布和主从复制

01，消息订阅发布

1.1，消息的订阅

• 进程间的一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

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

1.2，消息的发布

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

1.3，消息订阅和发布的常用命令

命令	描述
PSUBSCRIBE pattern [pattern …]	订阅一个或多个符合给定模式的频道。
PUBSUB subcommand [argument [argument …] ]	查看订阅与发布系统状态。
PUBLISH channel message	将信息发送到指定的频道。
PUNSUBSCRIBE [pattern [pattern …]]	退订所有给定模式的频道。
SUBSCRIBE channel [channel …]	订阅给定的一个或多个频道的信息。
UNSUBSCRIBE [channel [channel …]]	指退订给定的频道

1.4，实例演示

• 使用客户端1订阅一个三个频道的信息：

122.1.0.1:6379> SUBSCRIBE channel1 channel2 channel3
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel1"
3) (integer) 1
1) "subscribe"
2) "channel2"
3) (integer) 2
1) "subscribe"
2) "channel3"
3) (integer) 3

# 下面的消息是客户端2给频道发信息时才会显示
1) "message"
2) "channel1"
3) "hello-welcome-subscribe-channel1"

• 使用客户端2给频道发信息，此时客户端1会收到信息

122.1.0.1:6379> PUBLISH channel1  hello-welcome-subscribe-channel1
(integer) 1

• 可以使用通配符订阅多个频道

# 订阅所有的以new开头的信息

PSUBSCRIBE new*

• 收取消息

PUBLISH new1 redis2015

02，主从复制

2.1，简介

• 主从复制：主机数据更新后根据配置和策略， 自动同步到备机的一种机制，或者称为master/slaver机制
• Master(主机)以写为主，Slave(从机)以读为主

2.2，具体作用

• 读写分离
• 容灾恢复

2.3，如何使用

为了演示主从复制，我们需要起三台linux，并在每天Linux中都安装Redis服务器

主redis	192.168.138.101
从redis	192.168.138.102
从redis	192.168.138.103

使用步骤
1，配从不配主，也就是我们只需要修改从机的配置文件即可
2，修改配置文件细节操作

从机中的redis的配置文件，我们可以使用redis[端口号].conf来重命名

配置文件修改的具体步骤（多台机都修改）：
第一步：开启daemonize yes
第二步：设定端口号，port 端口号
第三步：设定pid文件名字，pidfile/var/run/redis[端口号].pid
第四步：设定log文件名字，logfile "端口号.log"
第五步：设定dump.rdb名字，dump[端口号].rdb

第六步：给从库设定主机，slaveof  主库IP 主库端口
第七步：如果主库设置密码，从库要进行如下设定：masterauth 主密码

3，从库配置命令：slaveof 主库IP 主库端口

如果第六步没有配置，每次与master断开之后，都需要重新连接
如果第六步配置了，此处可以省略

4，依次启动三台机的Redis服务器：101,102,103

注意启动顺序
启动后可以在redis客户端使用命令：info replication 查看信息

5，向主库中写东西，查看从库是否会同步

向从redis写入数据失败，默认slave-read-only yes，如果为no则可以向从写数据

2.4，容灾处理

在上面的配置中，当Master服务出现故障：

• 第一种：从机Slave原地待命，直至等到主机重启，继续执行主从复制
• 第二种：主机重启不了，需手动将Slave中的一个提升为master， 剩下的Slave挂至新的Master上（冷处理：机器挂掉了，再处理）

如何提升从机为主机的步骤：

第一步：关闭主服务器

第二步：将一台slave服务器提升为Master，在一台从机的客户端执行:slaveof no one

第三步：将slave挂至新的Master上，在Slave的客户端执行：slaveof 主机IP 主库端口

第四步：在主机和从机客户端执行：info replication 查看信息

如果从机出现故障：

• 第一种：没有在从机配置文件中配置slaveof 主库IP 主库端口，重启从机后需要再次在从机的客户端执行：slaveof 主库IP 主库端口
• 第二种：在从机配置文件中配置slaveof 主库IP 主库端口，重启从机即可连接

2.5，主从复制原理

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

2.6，哨兵模式

何为哨兵模式

• 一组sentinel能同时监控多个master
• 反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

如何使用

主机101，端口号6379
从机102，端口6380
从机103，端口6381

第一步：新建sentinel.conf文件，名字绝不能错，配置哨兵，填写内容

sentinel monitor 被监控数据库名字(自己起名字) 122.1.0.1 6379 1
上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机

第二步：启动哨兵

redis-sentinel   /myredis/sentinel.conf （上述目录依照各自的实际情况配置，可能目录不同）

正常主从演示
原有的master挂了
投票新选
重新主从继续开工，info replication查查看

问题：如果之前挂了的master重启回来，会不会双master冲突 ?

• 答： 不会，原master，变成slave

2.7，主从复制的缺点

复制延时

• 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重

2.8，补充

主从问题演示

• 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制？

  • 答：从头开始复制；123也可以复制

• 从机是否可以写？set可否？

  • 答：从机不可写，不可set，主机可写

• 主机shutdown后情况如何？从机是上位还是原地待命

  • 答：从机还是原地待命（咸鱼翻身，还是咸鱼）

• 主机又回来了后，主机新增记录，从机还能否顺利复制？

  • 答：能

• 其中一台从机down后情况如何？依照原有它能跟上大部队吗？

  • 答：不能跟上，每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件（具体位置：redis.conf搜寻，REPLICATION）

• 从机中途变更转向新的主机，之前的数据还存在吗？

  • 答： 会清除之前的数据，重新建立拷贝最新的
  • slaveof 新主库IP 新主库端口

• 如何把从机变为主机

  • 使用命令：SLAVEOF no one