Redis学习笔记_04：Redis持久化+Redis发布订阅+Redis主从复制

Redis学习笔记_04

本文基于B站UP主【遇见狂神说】视频教程 【Redis最新超详细版教程通俗易懂】进行整理/记录，仅用于个人学习交流使用

狂神主页：https://space.bilibili.com/95256449

视频地址：https://www.bilibili.com/video/BV1S54y1R7SB

Redis官方中文文档：http://www.redis.cn/

参考博客：https://blog.csdn.net/DDDDeng_/article/details/108118544

参考博客：https://blog.csdn.net/lisen01070107/article/details/108507798

八、Redis持久化

面试和工作，持久化都是重点

Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能！

1.RDB（Redis DataBase）

什么是RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置！

有时候在生产环境我们会将这个文件进行备份！

rdb保存的文件是dump.rdb 都是在我们的配置文件中快照中进行配置的！

触发机制

• 1、save的规则满足的情况下，会自动触发rdb规则
• 2、执行 flushall 命令，也会触发我们的rdb规则！
• 3、退出redis，也会产生 rdb 文件！

备份就自动生成一个 dump.rdb

如果恢复rdb文件！

1、只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据！

2、查看需要存在的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" # 如果在这个目录下存在 dump.rdb文件，启动就会自动恢复其中的数据

几乎就他自己默认的配置就够用了，但是我们还是需要去学习！

优点：

• 1、适合大规模的数据恢复！
• 2、对数据的完整性要求不高！

缺点：

• 1、需要一定的时间间隔进程操作！如果redis意外宕机了，这个最后一次修改数据就没有的了！
• 2、fork进程的时候，会占用一定的内容空间！！

2.AOF（Append Only File）

将我们的所有命令都记录下来，history，恢复的时候就把这个文件全部在执行一遍！

是什么

以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

Aof保存的是 appendonly.aof 文件

什么是AOF

快照功能（RDB）并不是非常耐久（durable）： 如果 Redis因为某些原因而造成故障停机，那么服务器将丢失最近写入、以及未保存到快照中的那些数据。 从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

如果要使用AOF，需要修改配置文件

appendonly no yes则表示启用AOF

默认是不开启的，我们需要手动配置，然后重启redis，就可以生效了！

如果这个aof文件有错位，这时候redis是启动不起来的，我需要修改这个aof文件

redis给我们提供了一个工具redis-check-aof --fix

优点和缺点

appendonly yes  # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分的情况下，rdb完全够用
appendfilename "appendonly.aof"

# appendfsync always # 每次修改都会sync 消耗性能
appendfsync everysec # 每秒执行一次 sync 可能会丢失这一秒的数据
# appendfsync no # 不执行 sync ,这时候操作系统自己同步数据，速度最快

append

默认是不开启的，我们需要手动进行配置！我们只需要将 appendonly 改为yes就开启了 aof！

重启，redis 就可以生效了！

如果这个 aof 文件有错误，这时候 redis 是启动不起来的吗，我们需要修复这个aof文件

redis 给我们提供了一个工具 redis-check-aof --fix

如果文件正常，重启就可以直接恢复了！

重写规则说明

aof 默认就是文件的无限追加，文件会越来越大

如果 aof 文件大于 64m，太大了！ fork一个新的进程来将我们的文件进行重写！

优点：

• 1、每一次修改都同步，文件的完整会更加好！
• 2、每秒同步一次，可能会丢失一秒的数据
• 3、从不同步，效率最高的！

缺点：

• 1、相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢！
• 2、Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化！

3.RDB和AOF选择

有点	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定

如何选择使用哪种持久化方式？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

九、Redis发布与订阅

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。微信、微博、关注系统！
Redis 客户端可以订阅任意数量的频道。

订阅/发布消息图：

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

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

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

命令：

命令	描述
PSUBSCRIBE pattern [pattern…]	订阅一个或多个符合给定模式的频道。
PUNSUBSCRIBE pattern [pattern…]	退订一个或多个符合给定模式的频道。
PUBSUB subcommand [argument[argument]]	查看订阅与发布系统状态。
PUBLISH channel message	向指定频道发布消息
SUBSCRIBE channel [channel…]	订阅给定的一个或多个频道。
UNSUBSCRIBE channel [channel…]	退订一个或多个频道

------------订阅端----------------------
127.0.0.1:6379> SUBSCRIBE sakura # 订阅sakura频道
Reading messages... (press Ctrl-C to quit) # 等待接收消息
1) "subscribe" # 订阅成功的消息
2) "sakura"
3) (integer) 1
1) "message" # 接收到来自sakura频道的消息 "hello world"
2) "sakura"
3) "hello world"
1) "message" # 接收到来自sakura频道的消息 "hello i am sakura"
2) "sakura"
3) "hello i am sakura"

--------------消息发布端-------------------
127.0.0.1:6379> PUBLISH sakura "hello world" # 发布消息到sakura频道
(integer) 1
127.0.0.1:6379> PUBLISH sakura "hello i am sakura" # 发布消息
(integer) 1

-----------------查看活跃的频道------------
127.0.0.1:6379> PUBSUB channels
1) "sakura"

原理

每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构， 结构的 pubsub_channels 属性是一个字典，这个字典就用于保存订阅频道的信息，其中，字典的键为正在被订阅的频道， 而字典的值则是一个链表， 链表中保存了所有订阅这个频道的客户端。

客户端订阅，就被链接到对应频道的链表的尾部，退订则就是将客户端节点从链表中移除。

缺点

• 如果一个客户端订阅了频道，但自己读取消息的速度却不够快的话，那么不断积压的消息会使redis输出缓冲区的体积变得越来越大，这可能使得redis本身的速度变慢，甚至直接崩溃。
• 这和数据传输可靠性有关，如果在订阅方断线，那么他将会丢失所有在短线期间发布者发布的消息。

应用

• 消息订阅：公众号订阅，微博关注等等（起始更多是使用消息队列来进行实现）
• 多人在线聊天室。

这边消息队列的功能相比MQ之类的就差很多了，所以稍微复杂的场景，我们就会使用消息中间件MQ处理。

十、Redis主从复制

1.概念

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（Master/Leader）,后者称为从节点（Slave/Follower）， 数据的复制是单向的！只能由主节点复制到从节点 （主节点以写为主、从节点以读为主）。

默认情况下，每台Redis服务器都是主节点，

一个主节点可以有0个或者多个从节点，但每个从节点只能由一个主节点。

最低配：一主二从

作用

• **数据冗余：**主从复制实现了数据的热备份，是持久化之外的一种数据冗余的方式。
• **故障恢复：**当主节点故障时，从节点可以暂时替代主节点提供服务，是一种服务冗余的方式
• **负载均衡：**在主从复制的基础上，配合读写分离，由主节点进行写操作，从节点进行读操作，分担服务器的负载；尤其是在读多写少的场景下，通过多个从节点分担负载，提高并发量。
• **高可用（集群）基石：**主从复制还是哨兵和集群能够实施的基础。

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的(宕机），原因如下︰

1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大;

2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"。对于这种场景，我们可以使如下这种架构︰

主从复制，读写分离!80%的情况下都是在进行读操作!减缓服务器的压力!架构中经常使用!一主二从!

只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis !

为什么使用集群

• 单台服务器难以负载大量的请求
• 单台服务器故障率高，系统崩坏概率大
• 单台服务器内存容量有限。

2.环境配置

我们在讲解配置文件的时候，注意到有一个replication模块 (见Redis.conf中第8条)

查看当前库的信息： info replication

127.0.0.1:6379> info replication
# Replication
role:master # 角色
connected_slaves:0 # 从机数量
master_replid:3b54deef5b7b7b7f7dd8acefa23be48879b4fcff
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
123456789101112

既然需要启动多个服务，就需 要多个配置文件。

准备多个配置文件：

每个配置文件对应修改以下信息：

• 端口号

• pid文件名

• 日志文件名

• rdb文件名

依次启动单个服务：

启动单机多服务集群：

ps -ef|grep redis

3.一主二从配置

默认情况下，每台Redis服务器都是主节点 ;

我们一般情况下只用配置从机就好了！

认老大！一主（79）二从（80，81）

使用SLAVEOF host port就可以为从机配置主机了。

然后主机上也能看到从机的状态：

我们这里是使用命令搭建，是暂时的，==真实开发中应该在从机的配置文件中进行配置，==这样的话是永久的

使用规则

1.从机只能读，不能写，主机可读可写但是多用于写。

 127.0.0.1:6381> set name sakura # 从机6381写入失败
(error) READONLY You can't write against a read only replica.

127.0.0.1:6380> set name sakura # 从机6380写入失败
(error) READONLY You can't write against a read only replica.

127.0.0.1:6379> set name sakura
OK
127.0.0.1:6379> get name
"sakura"
12345678910

2.当主机断电宕机后，默认情况下从机的角色不会发生变化 ，集群中只是失去了写操作，当主机恢复以后，又会连接上从机恢复原状。

3.当从机断电宕机后，若不是使用配置文件配置的从机，再次启动后作为主机是无法获取之前主机的数据的，若此时重新配置称为从机，又可以获取到主机的所有数据。这里就要提到一个同步原理。

4.第二条中提到，默认情况下，主机故障后，不会出现新的主机，有两种方式可以产生新的主机：

- 从机手动执行命令slaveof no one,这样执行以后从机会独立出来成为一个主机
- 使用哨兵模式（自动选举）

复制原理

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

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

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

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

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

层层链路模型

一个S连接另一个S

也可以实现主从复制

如果没有老大了，这个时候能不能选择出来一个老大呢？手动！

如果主机断开了连接，我们可以使用SLAVEOF no one让自己变成主机！其他的节点就可以手动连接到最新的主节点（手动）！如果这个时候老大修复了，那么就重新连接！

手动的！