【redis学习篇】主从&哨兵&集群架构详解

1. 单点Redis的问题

数据丢失问题

Redis是内存存储，服务重启可能会丢失数据

并发能力问题

单节点Redis并发能力虽然不错，但也无法满足如618这样的高并发场景

故障恢复问题

如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段

存储能力问题

Redis基于内存，单节点能存储的数据量难以满足海量数据需求

2. Redis持久化 -> 数据丢失问题

RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称为RDB文件，默认是保存在当前运行目录。

save命令：由于redis是单线程执行的，使用此save命令时，主进程会阻塞其它的命令，而将数据持久化到磁盘的耗时比较久，等到save命令结束，主进程才能执行其它命令。不推荐使用此命令，它通常用在Redis停机时使用。

bgsave命令：后台异步执行，它会开启子进程执行RDB，避免主进程收到影响，推荐使用该命令作RDB。

Redis停机时会自动执行一次RDB（通过redis-cli连接上redis服务之后，输入shutdown命令即可让redis服务停止或者在redis未开启以守护模式运行时通过ctrl+c停止运行时，会自动执行一次RDB）。

linux单机安装Redis步骤

首先需要安装Redis所需要的依赖：

yum install -y gcc tcl

然后将课前资料提供的Redis安装包上传到虚拟机的任意目录：

例如，我放到了/tmp目录：

解压缩：

tar -xvf redis-6.2.4.tar.gz

解压后：

进入redis目录：

cd redis-6.2.4

运行编译命令：

make && make install

如果没有出错，应该就安装成功了（redis的默认安装位置是/usr/local/bin，在此/usr/local/bin目录下有：redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件；同时在redis-6.2.4目录下有redis.conf和sentinel.conf配置文件；同时在redis-6.2.4目录下的是src目录中也有redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件）。

然后修改redis.conf文件中的一些配置：

# 绑定地址，默认是127.0.0.1，会导致只能在本地访问。修改为0.0.0.0则可以在任意IP访问
bind 0.0.0.0# 数据库数量，设置为1
databases 1

启动Redis：

redis-server redis.conf # 使用redis-server命令启动redis, 并指定配置文件; 其中redis-server命令可在任意目录下执行

停止redis服务：

redis-cli shutdown # 其中redis-cli命令可在任意目录下执行

RDB持久化与恢复示例

按照【单机安装Redis步骤】中的步骤安装好redis后：

• 在/usr/local/bin目录下有redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件，并且
• 在/usr/local/redis6/redis6.2.4/src目录下也有这些可执行文件；
• 在/usr/local/redis6/redis6.2.4/src下有redis.conf和sentinel.conf配置文件。

（这里主要是说明安装情况）

在如上安装好redis之后，这里演示下在关闭redis服务时，redis会自动执行RDB的案例

现在切换/usr/local/redis6/redis-6.2.4目录下（不是必须在这个目录，在其它目录也可以执行redis-server命令）

使用redis-server ./redis.conf 命令，来指定对应的配置文件启动redis服务，redis开始接收连接

现在开启另外1个窗口，使用set num 123来保存1条数据到redis内存中，然后发出shutdown的命令，让redis关闭服务，此时redis服务会自动做1次RDB操作，将内存中的数据持久化到dump.rdb文件中（此dump.rdb文件默认会生成在运行redis-server命令时所在的目录中，这里在/usr/local/redis6/redis-6.2.4目录下）

现在/usr/local/redis6/redis-6.2.4目录下，继续在重新启动redis服务，查看前面通过RDB持久化的文件是否恢复到内存当中（这里就没有指定redis.conf了，也可以指定对应的配置文件）

在另外1个窗口，使用redis-cli连接上redis服务，查看数据，发现数据没有丢失，说明redis能够从持久化的文件恢复到内存中

RDB机制

上面案例演示了在redis服务关闭时，会自动执行RDB命令，将内存中的数据持久化到磁盘中。但是，假设redis运行过程中，突然宕机了，此时还没持久化到磁盘中，那么在存储在redis内存中的数据将会全部丢失，所以redis应该要有一套自动持久化的机制。

Redis内部有触发RDB的机制，可以在redis.conf文件中找到（这3个配置默认是被注释的，默认情况下RDB是开启的），格式如下：

RDB的其它配置也可以在redis.conf文件中设置：

（配置的含义就是 在指定的一段时间内，有指定数量的key被修改了，那么就执行1次RDB操作，将内存中的数据持久化到指定的目录下的指定的文件中。当然，redis启动时，也会从这个指定的目录下查找这个指定的文件加载到内存中。）

当有了RDB后，即使不关闭redis服务，也能通过配置将redis内存中的数据持久化到磁盘上，但是它会每隔一段时间，才会执行RDB操作。如果在某段时间内，尚未执行RDB时，此时宕机了，那么这段时间内的数据就丢失了。所以，可能会想着把间隔时间设置的尽可能短，但如果间隔时间很短，执行RDB的操作就太频繁了，影响redis的性能。所以使用默认的就好了。

RDB配置示例

说明：5s内，如果有1个key发生变化，那么持久化内存钟的数据到指定的文件中。其中，修改redis.conf文件部分如下：

# 5s内，如果有1个key发生变化, 则触发1次RDB持久化（如果需要禁用RDB, 则配置: save "" 即可）
save 5 1# 指定持久化文件的名字
dbfilename test.data  # 指定RDB持久化文件的所在目录
dir ./my_data_dir

在/usr/local/redis6/redis-6.2.4下创建rdb_test目录，并在此rdb_test目录下创建my_data_dir文件夹用于存放持久化文件。修改号redis.conf配置文件后，使用该配置文件启动redis。

redis启动后，使用redis-cli连接上redis服务，并向redis中存储2条数据，然后观察redis服务的控制台上观察输出，看到了redis执行持久化的日志，关闭redis后，查看my_data_dir文件夹，看到了test.data数据持久化文件

再次使用指定的配置文件，启动redis，使用redis-cli再次查询数据，发现数据已恢复

RDB的fork原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。（bgsave是异步执行持久化的，对主进程几乎零阻塞，零阻塞的原因在于主进程在执行fork得到子进程时，此fork操作会阻塞，此时无法处理客户端请求）

fork采用的是copy-on-write技术：

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作（当此时针对很多key写操作时，就相当于要拷贝大量数据作为副本，此时就需要事先考虑给redis预留足够的空间）

总结

RDB方式bgsave的基本流程？

• fork主进程得到一个子进程，共享内存空间
• 子进程读取内存数据并异步写入新的RDB文件
• 用新RDB文件替换旧的RDB文件。

RDB会在什么时候执行？save 60 1000代表什么含义？

• 默认是服务停止时。
• 代表60秒内至少执行1000次修改则触发RDB

RDB的缺点？

• RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
• fork子进程、压缩、写出RDB文件都比较耗时

AOF持久化

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

AOF的命令记录的频率也可以通过redis.conf文件来配：

配置项	刷盘时机	优点	缺点
Always	同步刷盘（redis接收到命令后，使用命令操作完内存后，把此命令写到AOF文件磁盘中，此时主进程是阻塞的，等到写完AOF才返回给用户，主进程再处理其它请求）	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘（redis接收到命令后，使用命令操作完内存后，把此命令写到内存缓冲区中，写完缓冲区后，主进程立即返回。1s后再通过异步的方式将缓冲区中的数据写到AOF文件磁盘中，因为主进程是面对内存缓冲区中的读写，所以效率高，但是如果在写入的过程中宕机了，那么就会丢失这1s内的所有操作。它是默认方案。）	性能适中	最多丢失1秒数据
no	操作系统控制（由操作系统决定，可能频率会比较低）	性能最好	可靠性较差，可能丢失大量数据

AOF配置示例

说明：AOF会记录每条执行的redis命令到aof文件中，这里关闭了rdb机制，开启了aof机制

# 关闭RDB机制
save ""# aof文件将会保存在此目录, 启动时会读取该目录下的aof文件（与RDB持久化文件所保存的目录相同）
dir ./aof_data_dir# 开启aof
appendonly yes# aof文件名
appendfilename "my_aof.data"# aof刷盘策略, 默认就是everysec, 不需要修改
appendfsync everysec

在/usr/local/redis6/redis-6.2.4下创建aof_test目录，并在此aof_test目录下创建aof_data_dir文件夹用于存放aof文件。修改好redis.conf配置文件后，使用该配置文件启动redis。

使用redis-cli客户端连接上redis服务，并且保存1条数据，然后退出redis-cli客户端，就可以在指定的目录下看到保存的aof文件了，并且这里看到了aof文件的内容，aof文件确实记录了每条redis命令

关闭redis时，redis也会执行1次aof

重新启动redis服务，会自动加载aof文件，然后使用redis-cli客户端连接上redis服务，查询redis服务关闭之前所保存的数据，能够查询到，说明aof文件被加载了

AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果（此命令为异步执行，他会让aof文件变小，并对内容作编码处理）。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

特点	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见

• RDB与AOF数据恢复优先级：当目录下同时存在AOF与RDB文件时，会优先使用AOF文件来恢复数据，因为AOF文件数据更加完整，而RDB会丢失从上次备份的数据后到发生故障时这段时间内的数据。所以RDB更适合作为一种数据备份的手段。

• AOF操作是异步的

3. Redis主从 -> 并发能力问题

主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群（而不是负载均衡的那种集群），实现读写分离（因为redis查询操作多，增删改比较少，所以需要更多的处理读的压力，实现读写分离，提高读的并发能力）。

搭建主从架构示例

集群架构

我们搭建的主从集群结构如图：

共包含三个节点，一个主节点，两个从节点。这里我们会在同一台虚拟机中开启3个redis实例，模拟主从集群，信息如下：

IP	PORT	角色
172.17.23.234	7001	master
172.17.23.234	7002	slave
172.17.23.234	7003	slave

准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

1）创建目录

我们在/usr/local/redis6/redis-6.2.4/master-slave-cluster目录下，创建三个文件夹，名字分别叫redis7001、redis7002、redis7003，和1个最初的redis.conf配置文件（未作任何修改）

修改redis.conf配置文件：将其中的持久化模式改为默认的RDB模式，AOF保持关闭状态；配置bind允许远程连接；虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息。然后，将此redis.conf分别拷贝到redis7001、redis7002、redis7003中，然后分别修改他们对应的端口为：7001，7002，7003。

# 开启RDB
# save ""
save 3600 1
save 300 100
save 60 10000# 关闭AOF
appendonly no# 允许远程连接（不设置此配置, 会无法同步）
bind 0.0.0.0# 虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息
replica-announce-ip 172.17.23.234# 这个目录在本示例中为了方便就不改了, 但是注意启动的时候, 需要到对应的目录下去启动, 否则rdb生成的文件会在redis-server的运行目录下
dir ./# 端口: redis7001、redis7002、redis7003中，然后分别修改他们对应的端口为：7001，7002，7003
port 7001 # 这里以7001为例

启动

分别在redis7001目录下启动7001，redis7002目录下7002，redis7003目录下7003（注意运行redis-server命令的目录，因为我们的dir配置的是./）

开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。

有临时和永久两种模式：

• 修改配置文件（永久生效）

  • 在redis.conf中添加一行配置：slaveof <masterip> <masterport>

• 使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

  slaveof <masterip> <masterport>
  

注意：在5.0以后新增命令replicaof，与salveof效果一致。

这里让7002成为7001的slave，即让7002成为7001的从节点，执行该命令后，就会把7001主节点的数据同步过来

让7003成为7001的slave，并且从节点只能读取数据，不能够写入数据，只有主节点才能写入数据

测试

在主节点中写入数据，再分别从7002、7003从节点中读取到了数据，证明主从数据同步成功了。可以执行info replication查看集群状态。

主从数据同步原理

主从的全量同步原理

主从第一次同步是全量复制

master如何判断slave是不是第一次来同步数据？这里会用到两个很重要的概念：

• Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
• offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据

全量同步过程：从节点将自己的replication id发给主节点，主节点判断此replication id是否与自己的replication id是否一致，如果replication id不一致，说明该从节点是第一次来，主节点需要执行bgsave命令来做RDB保存起来，然后将自己的全量数据和offset同步到该从节点；如果replication id一致，说明从节点之前已经来过了，做过了全量同步了，并且从节点将offset也发过来了，因此主节点就可以从offset得知从节点的同步进度，因此主节点就将offset后面的数据发过去给从节点）

简述全量同步的流程

• 第1步：slave与master建立连接

• 第2步：slave节点请求增量同步

• 第3步：master节点判断replid，发现不一致，拒绝增量同步

• 第4步：master将完整内存数据生成RDB，发送RDB到slave

• 第5步：slave清空本地数据，加载master的RDB

• 第6步：master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave

• 第7步：slave执行接收到的命令，保持与master之间的同步

主从的增量同步原理

主从第一次同步是全量同步，，但如果slave重启后同步，则执行增量同步。

增量同步过程：从节点重启后，依然需要携带自己的replid和offset向主节点请求同步数据，主节点收到该节点发过来的replid后，与自己的replid比较，发现一致，说明不是第一次来同步的，因此，就查看该节点发过来的offset查看该节点之前的同步进度，然后从repl_baklog中读取大于此offset的命令发送给从节点去同步。如果主节点这边检测到该未同步的数据已经被覆盖了，那么就会要求该节点做全量同步。

repl_baklog大小有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，此时只能再次全量同步。

主从数据同步优化点

可以从以下几个方面来优化Redis主从就集群：

• 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO（需要网络带宽足够大）。

• Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO

• 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步

• 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

  

总结

简述全量同步和增量同步区别？

• 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
• 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

• slave节点第一次连接master节点时
• slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

• slave节点断开又恢复，并且在repl_baklog中能找到offset时

4. Redis哨兵 -> 故障恢复问题

5. Redis分片集群 -> 存储能力问题