企业网站建设心得进入百度官网首页
目录
前言
七、事务管理
7.1事务中的异常处理
八、订阅发布
8.1概述
8.2.Redis针对发布订阅相关指令
九、主从复制
9.1主从复制概述
9.2.主从复制的用处
9.3主从复制实现原理
9.3.1.psync指令
9.3.2.复制偏移量
9.3.3复制积压缓冲区&节点ID
前言
今天接着分享redis，本次分享的主要是事务管理、订阅发布和主从复制。
七、事务管理
事务的本质，其实就是一组命令的集合。一个事务中的所有命令都会按照命令的顺序去
执行，而中间不会被其他命令加塞。
7.1事务中的异常处理
-
命令语法错误。针对语法错误，会导致整个事务执行被中断
-
运行操作错误针对执行中的异常，只会导致该条指令的执行失败，而不会影响事务中其他的指令。
八、订阅发布
8.1概述
如果熟悉消息中间件，那么对发布订阅一定不陌生。发布者Publish一条消息，消息发送
到Channel通道中，然后所有订阅了这个通道的订阅者Subscriber都会接收到这条消息。
如下图所示：
8.2.Redis针对发布订阅相关指令
九、主从复制
9.1主从复制概述
主从复制，是指将一台Redis服务器的数据复制到其他的Redis服务器。前者称为主节点
（Master/Leader），后者称为从节点（Slave/Follower）；数据是从主节点复制到从节
点的。其中，主节点负责写数据（当然有读的权限），从节点负责读数据（它没有写数
据的权限）。默认的配置下，每个Redis都是主节点。
一个主节点可以有多个从节点，但是一个从节点只能有一个主节点，即：主从节点是1对N的关系。
9.2.主从复制的用处
- 数据冗余。主从复制实现了数据的备份，实际上提供了数据冗余的实现方式。
- 故障恢复。当主节点出现异常时，可以由从节点提供服务，实现快速的故障恢复，实际上提供了服务冗余的实现方式。
- 负载均衡。在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器的负载；在写少读多的业务场景下，通过多个从节点分担读负载，可以大大提高Redis服务器是并发量。
- 高可用。哨兵配合主从复制，可以是实现Redis集群的高可用。
9.3主从复制实现原理
Redis的主从复制可以分为两个阶段：sync阶段和command propagate阶段。当从节点启
动后，会发送sync指令给主节点，要求全量同步数据，此为sync阶段；那么，如果后续
Master节点接收到新的增删改操作，也需要Slave节点接收同步的更新，这就是command
propagate阶段；
9.3.1.psync指令
当主从节点都正在运行的时候，出现了网络抖动，造成连接断开，那么当网络恢复，两个
节点再次建立起连接的时候。从节点发送sync指令后，主节点依然需要重新生成RDB，并
对从节点进行全量数据的同步造成。那么这中间的耗时是非常严重的，并且传输备份文件
也会对网络带宽造成很大的消耗。那么为了解决这个问题，从Redis 2.8开始，引入了psync指令来代替sync指令。psync指令会根据不同的情况，来确定执行全量重同步还是部分重同步。
- 全量重同步。当从节点是第一次与主节点建立连接的时候，那么就会执行全量重同步，这个同步过程与上面我们介绍的sync阶段+command propagate阶段一样。
- 部分重同步。从节点的复制偏移量无法在复制积压缓冲区中找相应待同步的数据 并且 主节点与从节点不是第一次同步（根据Redis节点ID判断）
9.3.2.复制偏移量
Master节点和Slave节点都保存着一份复制偏移量。当Master节点每次向Slave节点发送n
字节数据的时候，就会在Master节点偏移量加上n；而Slave节点每次接收到n个字节的
时候，也会在Slave节点偏移量上加n。在命令传播阶段，Slave节点会定期的发送心跳
REPLCONF ACK{offset}指令，这里的offset就是Slave节点的offset。当Master节点接
收到这个心跳指令后，会对比自己的offset和命令里的offset，如果发现有数据丢失，那
么Master节点就会推送丢失的那段数据给Slave节点。如下图所示：
9.3.3复制积压缓冲区&节点ID
什么是复制积压缓冲区？
复制积压缓冲区是由主节点维护的一个固定长度（默认1MB）的队列。它存储了每个字
节值与对应的复制偏移量。因为复制积压缓冲区的大小是固定的，所以它保存的是主节点近
期执行的写命令。当从节点将offset发送给主节点后，主节点便会根据offset与复制积压缓
冲区的大小来决定是否可以使用部分重同步。如果offset之后的数据仍然在复制积压缓冲区
内，则执行部分重同步；否则还是执行全量重同步。
节点ID
Redis节点服务启动之后，就会产生一个用来唯一标识Redis节点的ID。当Master节点与
Salve节点进行第一次连接同步的时候，Master节点会将ID发送给Slave节点，Slave节点接收
到会对其进行保存。那么当主从服务之间发生了中断重连的时候，Slave服务器会将这个ID
发送给Master服务器，Master服务器会拿自己的ID进行对比，如果相同，则说明主从之前是
连接过的。否则，则说明是第一次建立的连接。那么，就需要全量去同步数据了。