一、数据持久化

Redis是一种内存型数据库，一旦服务器进程退出，数据库的数据就会丢失，为了解决这个问题Redis供了两种持久化的方案，将内存中的数据保存到磁盘中，避免数据的丢失两种持久化方式：快照（RDB文件）和追加式文件（AOF文件），下面分别为大家介绍两种方式的原理。

• RDB持久化方式会在一个特定的间隔保存那个时间点的数据快照。
• AOF持久化方式则会记录每一个服务器收到的写操作。在服务启动时，这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟Redis协议一致，以追加的方式进行保存。
• Redis的持久化是可以禁用的，就是说你可以让数据的生命周期只存在于服务器的运行时间里。
• 两种方式的持久化是可以同时存在的，但是当Redis重启时，AOF文件会被优先用于重建数据。

1.1 RDB持久化

RDB持久化产生的文件是一个经过压缩的二进制文件，这个文件可以被保存到硬盘中，可以通过这个文件还原数据库的状态，它可以手动执行，也可以在redis.conf配置文件中配置，定时执行。

1.1.1 工作原理

在进行RDB时，redis的主进程不会做io操作，会fork一个子进程来完成该操作：

1）Redis 调用forks。同时拥有父进程和子进程。

2）子进程将数据集写入到一个临时 RDB 文件中。

3）当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益(因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求)

1.1.2 触发机制

在Redis中RDB持久化的触发分为两种：自己手动触发与自动触发。

1.1.2.1 手动触发

• save

save命令是同步的命令，会占用主进程，会造成阻塞，阻塞所有客户端的请求

• bgsave

bgsave是异步进行，进行持久化的时候，redis还可以将继续响应客户端请求

bgsave和save对比

1.1.2.2 自动触发

触发条件

save自动触发配置，见下面配置，满足m秒内修改n次key，触发rdb

# 时间策略 save m n m秒内修改n次key，触发rdb

save 900 1

save 300 10

save 60 10000

# 文件名称

dbfilename dump.rdb

# 文件保存路径

dir /home/work/app/redis/data/

# 如果持久化出错，主进程是否停止写入

stop-writes-on-bgsave-error yes

# 是否压缩

rdbcompression yes

# 导入时是否检查

rdbchecksum yes

1）从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发bgsave命令；

2）执行flushall命令，会触发rdb

3）退出redis，且没有开启aof时

1.1.3 RDB优缺点

1.1.3.1 优点

1）RDB 的内容为二进制的数据，占用内存更小，更紧凑，更适合做为备份文件；

2）RDB 对灾难恢复非常有用，它是一个紧凑的文件，可以更快的传输到远程服务器进行 Redis 服务恢复；

3）RDB 可以更大程度的提高 Redis 的运行速度，因为每次持久化时 Redis 主进程都会 fork() 一个子进程，进行数据持久化到磁盘，Redis 主进程并不会执行磁盘 I/O 等操作；

4）与 AOF 格式的文件相比，RDB 文件可以更快的重启。

1.1.3.2 缺点

1）因为 RDB 只能保存某个时间间隔的数据，如果中途 Redis 服务被意外终止了，则会丢失一段时间内的 Redis 数据。

2）RDB 需要经常 fork() 才能使用子进程将其持久化在磁盘上。如果数据集很大，fork() 可能很耗时，并且如果数据集很大且 CPU 性能不佳，则可能导致 Redis 停止为客户端服务几毫秒甚至一秒钟。

1.2 AOF持久化

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

1.2.1 AOF配置项

# 默认不开启aof 而是使用rdb的方式

appendonly no

# 默认文件名

appendfilename "appendonly.aof"

# 每次修改都会sync 消耗性能

# appendfsync always

# 每秒执行一次 sync 可能会丢失这一秒的数据

appendfsync everysec

# 不执行 sync ,这时候操作系统自己同步数据，速度最快

# appendfsync no

AOF的整个流程大体来看可以分为两步，一步是命令的实时写入（如果是appendfsync everysec 配置，会有1s损耗），第二步是对aof文件的重写。

1.2.2 AOF 重写机制

随着Redis的运行，AOF的日志会越来越长，如果实例宕机重启，那么重放整个AOF将会变得十分耗时，而在日志记录中，又有很多无意义的记录，比如我现在将一个数据 incr一千次，那么就不需要去记录这1000次修改，只需要记录最后的值即可。所以就需要进行 AOF 重写。

Redis 提供了bgrewriteaof指令用于对AOF日志进行重写，该指令运行时会开辟一个子进程对内存进行遍历，然后将其转换为一系列的 Redis 的操作指令，再序列化到一个日志文件中。完成后再替换原有的AOF文件，至此完成。

同样的也可以在redis.config中对重写机制的触发进行配置：

通过将no-appendfsync-on-rewrite设置为yes，开启重写机制；auto-aof-rewrite-percentage 100意为比上次从写后文件大小增长了100%再次触发重写；

auto-aof-rewrite-min-size 64mb意为当文件至少要达到64mb才会触发制动重写。

1.2.3 触发方式

在Redis中AOF持久化的触发也分为两种：自己手动触发与自动触发。

1.2.3.1 手动触发

bgrewriteaof

1.2.3.2 自动触发

就是根据配置规则来触发，当然自动触发的整体时间还跟Redis的定时任务频率有关系。

1.2.4 AOF的优缺点

1.2.4.1 优点

• 数据安全

aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。

• 解决数据一致性问题。

通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。

• AOF 机制的 rewrite 模式。

AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)

1.2.4.2 缺点

• AOF 文件比 RDB 文件大，且恢复速度慢。
• 数据集大的时候，比 rdb 启动效率低。

1.3 rdb与aof对比

二、发布与订阅

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

redis通过PUBLISH和SUBSCRIBE等命令实现了订阅与发布模式，这个功能提供两种信息机制，分别是订阅/发布到频道、订阅/发布到模式的客户端。

2.1 频道

2.1.1 发布

发布者发布消息

发布者向频道channel:1发布消息hi

127.0.0.1:6379> publish channel:1 hi

(integer) 1

2.1.2 订阅

订阅者订阅消息

127.0.0.1:6379> subscribe channel:1

Reading messages... (press Ctrl-C to quit)

1) "subscribe" // 消息类型

2) "channel:1" // 频道

3) "hi" // 消息内容

执行subscribe后客户端会进入订阅状态，仅可以使subscribe、unsubscribe、psubscribe和punsubscribe这四个属于"发布/订阅"之外的命令

订阅频道后的客户端可能会收到三种消息类型

• subscribe。表示订阅成功的反馈信息。第二个值是订阅成功的频道名称，第三个是当前客户端订阅的频道数量。
• message。表示接收到的消息，第二个值表示产生消息的频道名称，第三个值是消息的内容。
• unsubscribe。表示成功取消订阅某个频道。第二个值是对应的频道名称，第三个值是当前客户端订阅的频道数量，当此值为0时客户端会退出订阅状态，之后就可以执行其他非"发布/订阅"模式的命令了。

2.1.3 数据结构

基于频道的发布订阅模式是通过字典数据类型实现的

struct redisServer {

// ...

dict *pubsub_channels;

// ...

};

其中，字典的键为正在被订阅的频道， 而字典的值则是一个链表， 链表中保存了所有订阅这个频道的客户端。

2.1.3.1 订阅（channel）

当使用subscribe订阅时，在字典中找到频道key（如没有则创建），并将订阅的client关联在链表后面。

当client 10执行subscribe channel1 channel2 channel3时，会将client 10分别加到 channel1 channel2 channel3关联的链表尾部。

2.1.3.2 发布

发布时，根据key，找到字典汇总key的地址，然后将msg发送到关联的链表每一台机器。

退订时，遍历关联的链表，将指定的地址删除即可。

2.2 模式（pattern）

pattern使用了通配符的方式来订阅

通配符中?表示1个占位符，*表示任意个占位符(包括0)，?*表示1个以上占位符。

所以当使用 publish命令发送信息到某个频道时， 不仅所有订阅该频道的客户端会收到信息， 如果有某个/某些模式和这个频道匹配的话， 那么所有订阅这个/这些频道的客户端也同样会收到信息。

2.2.1 发布

发布者发布消息

127.0.0.1:6379> publish b m1

(integer) 1

127.0.0.1:6379> publish b1 m1

(integer) 1

127.0.0.1:6379> publish b11 m1

(integer) 1

2.2.2 订阅

订阅者订阅消息

127.0.0.1:6379> psubscribe b*

Reading messages... (press Ctrl-C to quit)

1) "psubscribe"

2) "b*"

3) (integer) 3

1) "pmessage"

2) "b*"

3) "b"

4) "m1"

1) "pmessage"

2) "b*"

3) "b1"

4) "m1"

1) "pmessage"

2) "b*"

3) "b11"

4) "m1"

2.2.3 数据结构

pattern属性是一个链表，链表中保存着所有和模式相关的信息。

struct redisServer {

// ...

list *pubsub_patterns;

// ...

};

// 链表中的每一个节点结构如下，保存着客户端与模式信息

typedef struct pubsubPattern {

redisClient *client;

robj *pattern;

} pubsubPattern;

2.2.3.1 发布

当发布者发布消息时，首先会发送到对应的频道上，在遍历模式列表，根据key匹配模式，匹配成功将消息发给对应的订阅者。

完成的发布伪代码如下：

def PUBLISH(channel, message):

# 遍历所有订阅频道 channel 的客户端

for client in server.pubsub_channels[channel]:

# 将信息发送给它们

send_message(client, message)

# 取出所有模式，以及订阅模式的客户端

for pattern, client in server.pubsub_patterns:

# 如果 channel 和模式匹配

if match(channel, pattern):

# 那么也将信息发给订阅这个模式的客户端

send_message(client, message)

2.2.3.2 订阅

当有信的订阅时，会将订阅的客户端和模式信息添加到链表后面。

2.2.3.3 退订

使用punsubscribe，可以将订阅者退订，将改客户端移除出链表。

2.3 使用场景

2.3.1 哨兵间通信

哨兵集群中，每个哨兵节点利用 Pub/Sub 发布订阅实现哨兵之间的相互发现彼此和找到 Slave。

哨兵与 Master 建立通信后，利用 master 提供发布/订阅机制在 `__sentinel__:hello`发布自己的信息，同时订阅这个频道来获取其他哨兵的信息，就这样实现哨兵间通信。

2.3.2 消息队列

我们也可以利用 Redis 发布订阅实现 **轻量级简单的 MQ 功能** ，实现上下游解耦，需要注意点是 Redis 发布订阅的消息不会被持久化，所以新订阅的客户端将收不到历史消息。

也不支持 ACK 机制，所以当前业务不能容忍这些缺点，那就使用专业的消息队列，如果能容忍那就能享受 Redis 快带来的优势。

今天关于Redis 数据持久化与发布订阅的相关内容就分享到这里！

如果对您有帮助，欢迎点赞+关注，也可以发表您宝贵的评论，和我一起互动！