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

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

第一个：消息发送者，第二个：频道，第三个：消息订阅者

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

?

以下操作需要打开两个redis-clc.exe

解释：右边是订阅端，订阅名“kuang”:subscribe kuang

左边是发布者，发布者发送消息到频道? publish kuang "hello"订阅端

"message"表示消息，“kuang”表示频道，“hello”和“hello vv”表示消息的具体内容

Redis通过PUBLISH? SUBSCRIBE? PSUBSCRIBE等命令实现订阅功能

微信公众号：

通过subscribe命令订阅某频道后redis-server里维护了一个字典，字典的键就是一个个频道，而字典的值是链表，链表中保存了所有订阅这个channel的客户端，subscribe命令的关键，就是将客户端添加到给定channel的订阅链表中。

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

pub/sub从字面上理解就是发布与订阅,在Redis中，你可以设定对某一个key值进行发消息以及消息订阅，当一个key值上进行消息发布后，所有订阅它的客户端都会收到相应的消息。比如群聊等。

使用场景

实时消息系统

实时聊天

订阅、关注系统

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器，前者称为主节点（master/leader）后者称为从节点(slave/follower)；

数据的复制只能是单向的，只能从主节点到从节点。Master以写为主，Slave以读为主

默认：每台Redis服务器都是主节点，且一个主节点可以有多个从节点（或者没有节点），但是一个从节点只能有一个主节点。

主从复制的作用：

1.数据冗余（除了持久化之外）

2.故障恢复（服务冗余）

3.负载均衡（分担服务器负载）

4.高可用基石（是哨兵和集群实施的基础）

对于这种场景，我们可以使用如下架构:

80%的情况在进行读操作

环境配置

只需要配置从库，不需要配置主库

查看当前库的信息：角色是master ,没有从机

至少打开三个端口

复制3个配置文件，然后修改对应的信息

1.port

2.pid名字

3.log文件名字

4.dump.rdb文件名

一般情况下只配置从机、

命令 slaveof? host? 6379

主机可以写，从机不能写，只能读

如果主机断开连接，从机依旧能连接到主机，但是不能写

如果使用命令行配置主从，这个时候重启就会变成主机，但是变回从机，就可以从主机中获取值

replication（复制原理）

Slave启动成功连接到master后会发送一个sync同步命令

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

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

增量复制：Master继续将新的收集的修改指令依次传给slave，完成同步

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

层层链路

上一个M（主节点）连接下一个S（从节点）

此时。中间的仍然是从节点，不能写。

当主机宕机，可以手动让自己变成主机，通过 : slaveof? no? one(手动)

如果此时主机修复，只能重新连接。