Redis基础—九、Redis订阅发布、Redis集群

Redis基础—九、Redis订阅发布、Redis集群

一、Redis订阅发布

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。

Redis 客户端可以订阅任意数量的频道。

应用场景：比如说广播，或者简单的聊天室都可以用到。

比如说下图就是仨：

后台先编辑一下channel1的信息发到channel中，之后所有订阅的用户都可以收到channel1的信息。

这里有一些常用的命令。

我们来实验一下：

接收端：

subscribe jjchanel            #订阅频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"    #订阅
2) "jjchanel"     #频道名
3) (integer) 1    #成功
1) "message"     #接受到信息
2) "jjchanel"    #哪个频道的信息
3) "hello!mybrother!"   #信息内容

发送端：

127.0.0.1:6379> publish jjchanel hello!mybrother!            #像jjchanel发送一条信息。
(integer) 1

原理

Redis是使用C实现的，通过分析Redis源码里的pubsub.c文件，了解发布和订阅机制的底层实现，籍此加深对Redis 的理解。Redis通过PUBLISH 、SUBSCRIBE和PSUBSCRIBE等命令实现发布和订阅功能。
微信:
通过SUBSCRIBE命令订阅某频道后，redis-server里维护了一个字典，字典的键就是一个个频道!，而字典的值则是一个链表，链表中保存了所有订阅这个channel的客户端。SUBSCRIBE命令的关键，就是将客户端添加到给定channel的订阅链表中。

通过PUBLSH命令向订阅者发送消息，redis-server会使用给定的频道作为键，在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。

Pub/Sub从字面上理解就是发布(Publish)与订阅( Subscribe )，在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

稍微复杂的场景，消息中间件MQ（RabbitMQ,KAFKA）

二、Redis集群

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(masterleader)，后者称为从节点(slave/follower);数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。

主从复制的作用主要包括:
1、数据冗余∶主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2、故障恢复∶当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复;实际上是一种服务的冗余。
3、负载均衡︰在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载﹔尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4、高可用（集群）基石︰除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

在一般的网站中，读的数量要大大的多于写的数量。（读多写少）所以说我们一般都会通过从机进行读操作，主机进行写操作。

首先我们进行一下环境的搭建：

1、环境配置

在配置环境之前，我们看一下主从复制的相关信息。

可以通过info replication查看相关的信息。

 info replication
# Replication
role:master      #角色，主机
connected_slaves:0   #从机数目
master_replid:36073baa6890d10d8be314be8d8b532a517695b9
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个redis服务，每个服务中的配置信息需要修改以下几项，防止冲突。

port 6379
dbfilename dump79.rdb
logfile "6379.log"
pidfile /var/run/redis_6379.pid

都启一下！启动成功！

2、主从复制

首先我们要先选一个端口的服务为老大，剩下俩为小弟。

这里我们指定6379端口的服务为老大，另外两个为小弟。

先启下客户端。

默认来说的话，自己就是主机。我们需要让他变为一个机器的从机

127.0.0.1:6380> info replication      
# Replication
role:master    #默认自己为主机
connected_slaves:0
master_replid:b060941bfa47734a979fbeec28b4893f33d444f9
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

我们配置一下：

SLAVEOF 127.0.0.1 6379                     #让其变为127.0.0.1(本机) 6379端口下的从机

再看一下主从信息，发现已经改变

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:70
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:bf1828b9149c216e0d30dec70289c2a8d20404ae
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:70
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:70
repl_backlog_histlen:14

主机中的主从信息也已经改变

role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=168,lag=0      #从机信息
master_replid:bf1828b9149c216e0d30dec70289c2a8d20404ae
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:168
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:168

我们将另一台从机也连接一下。

连接好之后，我们在主机中设置一个值。

127.0.0.1:6379> set k1 v1
OK

我们发现在从机中也是可以读取到的。

但是从机中无法写入值（就是上面我们所说的：主写，从读）

127.0.0.1:6380> set k2 v2
(error) READONLY You can't write against a read only replica.  

当主机宕机之后，从机的数据依然可以保持。

但是通过我们这种方式配置的从机如果宕机了，当他重新启动的时候，他就默认又变为了主机身份，正确的做法应该是去配置文件中进行主从的配置。

 replicaof <masterip> <masterport>         #设置主机 ip 端口号               

 masterauth <master-password>             #主机的密码

复制原理

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

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

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

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

层层链路

我们刚才配置的主从关系是这样的

还有一种模式是这样的

这样的话等于说中间那台机器既充当了主机，也充当了从机。

我们看一下中间机器的角色。

# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:2222
slave_priority:100
slave_read_only:1
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=2222,lag=1
master_replid:bf1828b9149c216e0d30dec70289c2a8d20404ae
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2222
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:2222

其角色还是从机，所以说他还是挺难顶的。

如果主机断开了连接，可以使用salveof no one这个命令来让自己成为主节点，

127.0.0.1:6380> slaveof no one
OK
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=2348,lag=0
master_replid:d439fc7e70d87c779cd974f2a4ff3de43595b9b3
master_replid2:bf1828b9149c216e0d30dec70289c2a8d20404ae
master_repl_offset:2348
second_repl_offset:2335
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:2348

其他的结点就可以手动连接到最新的这个主节点。

如果这个时候老大修复了，那就只能重新连接。

3、哨兵模式

我们之前的方法，如果主机宕机了，需要手动配置新的主机。这种方式如果在有许多机器的时候非常麻烦，还会造成一段时间的服务器不可用，这不是一种好的方式。

这时候redis从2.8开始正式提供了哨兵模式给我们，他会自动给所有服务器发送消息，如果主服务器在一定时间内没有响应，他就会认为这个主机挂掉了，去选举新的主机。它能够后台监控主机是否故障，如果故障了根据投票数自动将库转换为主库

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例

哨兵有两个作用

1. 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
2. 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让他们切换主机

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

测试一下！

测试

首先我们先要自己创建一个哨兵的配置sentinel.conf 。

# sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1 
# 1是有多少哨兵认为挂了，master才是真的挂了

我们这里认为6379的机器是主机。

这里我们将6380、6381都设置为6379的从机。

启动redis-sentinel。

redis-sentinel rconf/sentinel.conf                     #启动的方式与server类似 后面是其配置文件的地址

它可以自动判定你的所属从机。

这时我们让主节点shutdown一下！

默认半分钟以内，哨兵就可以检测到你主节点宕机了，他就会自动投票（有对应的投票算法，感兴趣的可以去了解一手），选出新的主节点。

这时我们也可以发现，6380变成了主节点，6379已经被选成为了6380的从节点，真是风水轮流转啊！

重启一下6379！看一下info。

确实！已经变成了从节点了。。

优点：

1. 哨兵模式，基于主从复制模式，所有主从配置的优点它都有
2. 主从可以切换，故障可以转移，系统的可用性就会更好
3. 哨兵模式就是主从模式的升级，手动到自动，更加健壮

缺点：

1. Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦
2. 实现哨兵模式的配置是非常麻烦的，里面有很多选择

刚才我们在配置文件中只配置了一条信息，但是真是开发环境中需要配置很多很多信息。

哨兵模式全部配置

# Example sentinel.conf
 
# 哨兵sentinel实例运行的端口 默认26379
port 26379
 
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 1
 
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
 
 
 
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。  
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
 
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，
#这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
#一个是事件的类型，
#一个是事件的描述。
#如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
#通知脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh