Redis学习笔记（六）

一、Redis发布订阅(Redis消息中间件的前身)

1.概念

1) Redis发布订阅即一种消息通信模式，发送者（PUBLISH）发送消息，订阅者（SUBSCRIBE）接收消息，可以实现进程间的消息传递。

2）发布/订阅其实是一个轻量的队列，只不过数据不会被持久化，一般用来处理实时性较高的异步消息。

2.实操

1）”subscribe c1 c2”即订阅c1、c2两个频道。

2）”publish c1 helloc1”向c1频道发送helloc1字符串消息。

3）psubcribe即按照模式批量订阅的Redis命令，可以用来订阅一个或者多个符合给定模式的频道。例如，” psubcribe c* a?”即订阅模式为”c*  a?”的频道，即订阅以c或者a开头的频道。其中*匹配多个字符，?匹配一个字符。

4)“pubsub numpat”即只统计使用psubcribe命令执行的，返回客户端订阅的唯一模式的数量（简单而言，返回客户端经psubcribe订阅的模式数量）。

5）”pubsub channels”即返回由活跃频道组成的列表。

6）”pubsub numsub c1”即返回c1频道有几个订阅者，通过通配符订阅频道的订阅者的不算入其中。

7）”unsubscribe c1”即取消对频道c1的订阅。

8)” punsubscribe a?”即取消对a开头频道的订阅，?匹配一个字符。

注：

1）在订阅之后再发布消息，订阅成功之前发布的消息是无法被订阅者收到的。若频道没有订阅者但是发布消息了，消息将被丢弃。

2）订阅的客户端每次可以收到一个带有3个参数的消息，参数分别是消息的种类、始发频道的名称（订阅频道的名称）、实际的消息内容。

3）这里的模式可以理解为模糊查询使用的匹配字符串（支持*号?号之类的）。

4）Redis发布订阅对于发布者而言消息是发送即失去的，因为Redis发布订阅不会管消息是否被接收与确认（ACK机制），也当然无法保证消息是否消费成功。

5）Redis发布订阅是Redis的Stream数据结构的前身。

 

二、Redis复制

1.概念

1）主从复制即master以写为主，slave以读为主。当master数据变化的时候，自动将新的数据异步同步到其他的slave数据库。这样可以达到读写分离的效果，还可以达成的其他效果在下面一一列举：

第一、容灾恢复，当master宕机时，slave因为完整保有主机（master）的数据而可以进行数据恢复。

第二、数据备份。

第三、水平扩容支撑高并发，即例如我们可以设置多个副机（slave）在同一个主机（master）下，从而使得我们的Redis服务器能够应对一定的高并发场景。

注：作为主机的Redis服务器即master，作为主机的副机Redis服务器即slave。

2）配置主副机时，只需要配置副机（slave），而不需要配置主机（master）。注意，若master配置了requirepass参数项，需要密码登录（即主机Redis服务器需要密码才能够访问），则slave就需要在配置文件中配置masterauth参数项以设置访问master时的校验密码。否则，master会拒绝slave的访问请求。

3)”info replication”可以查看复制节点的主从关系和配置信息。

4)Redis配置项replicaof 可以配置主机的IP和端口，即”replicaof 主机IP 主机Redis服务端端口”。本配置项在副机（即从机） 上配置，从而使得副机知晓谁是它的master，并从哪一个端口访问主机的Redis服务端。

5）Redis命令slaveof，slave每次从master上断开后，都需要重新连接，除非通过修改Redis配置文件进行永久的修改。slaveof是一种能够临时更改slave的master 的命令，它可以在运行期间修改slave的节点信息。如果一个机子已经是某个master的slave，那么通过这个命令可以临时修改该机的master，并停止该机与原本master的数据库的同步关系。例如”slaveof 主机IP 主机Redis服务端端口”。

注：slaveof是临时命令，也就意味着，即使我们将一台机器设置为另一台机器的slave，但是在这个临时的slave停机或者宕机重启后，它就会恢复原样，不再是任何机器的slave。除非，我们使用配置文件将其定义为一台机器的slave，那么，这个配置就是永久的。还有，若我们想通过slaveof指定的master拥有访问密码，则我们必须在slave机的Redis配置文件中指定配置文件项masterauth，即指定master的Redis服务端访问密码，否则无法连接。

6）”slaveof no one”即Redis命令，作用是使得当前slave停止与其master的数据库进行同步，不再是其他的master的slave，但是以前跟master同步的数据不会因为停止与其master的数据库进行同步而清空。

 

2.实操配置（配置一主一从）

第一、主机配置部分

1）注意防火墙配置保证三台机器能够相互ping通。

2）Redis配置文件项daemonize改为yes（daemonize即是否开启后台运行Redis服务端）。

3）Redis配置文件项 protected-mode改为no（关闭protected-mode即可让其他机器对本机的Redis服务端进行连接）。

4）注释掉Redis配置文件项 bind 127.0.0.1（即让我们的Redis服务端不仅支持本机访问，并关闭IP限制，从而可以进行远程访问和连接）。

5）Redis配置文件项port指定端口。

6）Redis配置文件项dir指定当前工作目录（路径要用绝对路径）。

7）Redis配置文件项pidfile指定pid文件的路径与名字。

8）Redis配置文件项logfile指定log文件的路径与名字。

9）Redis配置文件项 requirepass设置Redis的密码。

10）Redis配置文件项dbfilename设置dump.rdb文件的名字。

11）Redis配置文件项开启AOF（本步骤非必须）。

注：前四步为基本配置

 

第二、副机配置部分（副机配置前10步与主机配置部分相同，下面继续副机配置部分）

1）Redis配置文件项replicaof配置主机IP和主机的Redis服务端端口，即”replicaof 主机IP 主机Redis服务端端口”。

2）Redis配置文件项masterauth配置主机Redis服务端访问密码，以便我们的副机可以访问主机，即masterauth “访问密码”。

 

第三、启动主副机，先启动master再启动slave（主机Redis服务端端口6379，副机Redis服务端端口6380）

注：这里启动副机Redis客户端时需要指定连接端口，否则就算配置文件中的port改成了6380，也只是Redis服务端启动的端口为6380，启动副机Redis客户端时不指定端口仍然会使用6379端口来连接Redis服务端，那么我们也就无法成功连接到我们副机的Redis服务端了。

 

第四、查看Redis配置文件项logfile指定log文件的名字对应的log文件，以查询我们主从机启动是否成功以及出错的话进行错误排查。

 

3.理论深入

1）slave只可以进行读操作，而不可以进行写操作。

2）若slave宕机master仍在继续写入新的数据，slave重启后会将master的数据拷贝一份进入slave中，然后master写一个，slave抄一个。并不会因为slave的宕机而导致slave重启后只会记录master新写入的数据，而抛弃旧数据。

3）当master宕机的时候，其如果有众多的slave，master的其中一个slave或者所有的slave并不会从slave身份转换成master。而是原地待命，等待master的重启，在此期间slave中的数据仍可以正常使用。等到master重启后，slave依旧会继续的记录master中的数据，一切照旧。

4）若是有一主二从，则两个slave中，其中的一个slave可以担当另一个slave的master，即slave同样可以接收其他slave的连接和同步请求，所用方法（命令）为slaveof。那么，接收其他slave连接和同步请求的slave在链条中对上而言是slave，对下而言是master。对于两个slave 的master而言，这样做有效的减轻了主master的压力。

注：中途变更master，会使得slave清除之前旧master的数据，并重新拷贝新master的数据。将上述一主二从因为关系变更产生的关系链的顶端的master称为主master，主master的slave是另一个slave 的master，但是这不代表主master的slave因为关系变更变成另一个slave 的master而就拥有了写权限。

 

4.总结

1）slave首次全新连接master，先会一次性完全同步master中的数据，并清空slave自身原本的数据，再遵循master写一条，slave抄一条的原则(即增量复制)。

2）完全同步master中的数据操作即master在收到slave 的同步命令后会使用RDB持久化，即主从复制会触发RDB，同时收集所有接收到的用于修改数据集的命令并缓存起来。Master节点执行RDB持久化完成后，master会将RDB文件和所有缓存的命令发送到所有的slave，以完成一次完全同步。slave在接收到数据库文件后，会将其存盘并加载到内存中，从而完成复制初始化。

3）在Reids配置文件中有默认配置项”repl-ping-replica-period 10”，即心跳包发送时间，每隔十秒master会发送一次心跳包确定slave是否存活。

4）master和slave都会保存一个复制的offset（偏移量）还有一个masterId，offset是保存在backlog中的。master只会把offset指向的数据之后的数据复制给slave。这也就意味着，当slave宕机时，master的offset会继续向前走。但是当slave重新开启时，slave 的offset会明显时落后于master的offset。所以，salve会将master的offset与slave的offset 之间落后的数据同步，以跟上master的脚步再进行增量复制。

5）master和slave中数据的同步是有一定的延时的，当系统繁忙与复杂的时候，这个问题会变得更加的严重。

6）master宕机的时候slave并不会自动上位（代替master的作用），需要人工手动干预（重启master），这也是Redis复制的一个致命问题。