缺点：按照此种方法，我们生产后的数据只能提供给各个单一消费者消费。能否实现生产一次就能让多个消费者消费呢?

③Pub/Sub：主题订阅者模式

发送者(Pub)发送消息，订阅者(Sub)接收消息。订阅者可以订阅任意数量的频道。

Pub/Sub模式的缺点：消息的发布是无状态的，无法保证可达。对于发布者来说，消息是“即发即失”的。

此时如果某个消费者在生产者发布消息时下线，重新上线之后，是无法接收该消息的，要解决该问题需要使用专业的消息队列，如 Kafka…此处不再赘述。

Redis 持久化

什么是持久化

持久化，即将数据持久存储，而不因断电或其他各种复杂外部环境影响数据的完整性。

由于 Redis 将数据存储在内存而不是磁盘中，所以内存一旦断电，Redis 中存储的数据也随即消失，这往往是用户不期望的，所以 Redis 有持久化机制来保证数据的安全性。

Redis 如何做持久化

Redis 目前有两种持久化方式，即 RDB 和 AOF，RDB 是通过保存某个时间点的全量数据快照实现数据的持久化，当恢复数据时，直接通过 RDB 文件中的快照，将数据恢复。

RDB(快照)持久化

RDB持久化会在某个特定的间隔保存那个时间点的全量数据的快照。

RDB 配置文件，redis.conf：

save 900 1 #在900s内如果有1条数据被写入，则产生一次快照。 save 300 10 #在300s内如果有10条数据被写入，则产生一次快照 save 60 10000 #在60s内如果有10000条数据被写入，则产生一次快照 stop-writes-on-bgsave-error yes #stop-writes-on-bgsave-error ： 如果为yes则表示，当备份进程出错的时候， 主进程就停止进行接受新的写入操作，这样是为了保护持久化的数据一致性的问题。

①RDB 的创建与载入

SAVE：阻塞 Redis 的服务器进程，直到 RDB 文件被创建完毕。SAVE 命令很少被使用，因为其会阻塞主线程来保证快照的写入，由于 Redis 是使用一个主线程来接收所有客户端请求，这样会阻塞所有客户端请求。

BGSAVE：该指令会 Fork 出一个子进程来创建 RDB 文件，不阻塞服务器进程，子进程接收请求并创建 RDB 快照，父进程继续接收客户端的请求。

子进程在完成文件的创建时会向父进程发送信号，父进程在接收客户端请求的过程中，在一定的时间间隔通过轮询来接收子进程的信号。

我们也可以通过使用 lastsave 指令来查看 BGSAVE 是否执行成功，lastsave 可以返回最后一次执行成功 BGSAVE 的时间。

②自动化触发 RDB 持久化的方式

自动化触发RDB持久化的方式如下：

• 根据 redis.conf 配置里的 SAVE m n 定时触发(实际上使用的是 BGSAVE)。
• 主从复制时，主节点自动触发。
• 执行 Debug Reload。
• 执行 Shutdown 且没有开启 AOF 持久化。

③BGSAVE 的原理

启动：

• 检查是否存在子进程正在执行 AOF 或者 RDB 的持久化任务。如果有则返回 false。
• 调用 Redis 源码中的 rdbSaveBackground 方法，方法中执行 fork() 产生子进程执行 RDB 操作。
• 关于 fork() 中的 Copy-On-Write。

fork() 在 Linux 中创建子进程采用 Copy-On-Write(写时拷贝技术)，即如果有多个调用者同时要求相同资源(如内存或磁盘上的数据存储)。

他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本给调用者，而其他调用者所见到的最初的资源仍然保持不变。

④RDB 持久化方式的缺点

RDB 持久化方式的缺点如下：

• 内存数据全量同步，数据量大的状况下，会由于 I/O 而严重影响性能。
• 可能会因为 Redis 宕机而丢失从当前至最近一次快照期间的数据。

AOF 持久化：保存写状态

AOF 持久化是通过保存 Redis 的写状态来记录数据库的。

相对 RDB 来说，RDB 持久化是通过备份数据库的状态来记录数据库，而 AOF 持久化是备份数据库接收到的指令：

• AOF 记录除了查询以外的所有变更数据库状态的指令。
• 以增量的形式追加保存到 AOF 文件中。

开启 AOF 持久化

①打开 redis.conf 配置文件，将 appendonly 属性改为 yes。

②修改 appendfsync 属性，该属性可以接收三种参数，分别是 always，everysec，no。

always 表示总是即时将缓冲区内容写入 AOF 文件当中，everysec 表示每隔一秒将缓冲区内容写入 AOF 文件，no 表示将写入文件操作交由操作系统决定。

一般来说，操作系统考虑效率问题，会等待缓冲区被填满再将缓冲区数据写入 AOF 文件中。

appendonly yes #appendsync always appendfsync everysec # appendfsync no

日志重写解决 AOF 文件不断增大

随着写操作的不断增加，AOF 文件会越来越大。假设递增一个计数器 100 次，如果使用 RDB 持久化方式，我们只要保存最终结果 100 即可。

而 AOF 持久化方式需要记录下这 100 次递增操作的指令，而事实上要恢复这条记录，只需要执行一条命令就行，所以那一百条命令实际可以精简为一条。

Redis 支持这样的功能，在不中断前台服务的情况下，可以重写 AOF 文件，同样使用到了 COW(写时拷贝)。

重写过程如下：

• 调用 fork()，创建一个子进程。
• 子进程把新的 AOF 写到一个临时文件里，不依赖原来的 AOF 文件。
• 主进程持续将新的变动同时写到内存和原来的 AOF 里。
• 主进程获取子进程重写 AOF 的完成信号，往新 AOF 同步增量变动。
• 使用新的 AOF 文件替换掉旧的 AOF 文件。

AOF 和 RDB 的优缺点

AOF 和 RDB 的优缺点如下：

• RDB 优点：全量数据快照，文件小，恢复快。
• RDB 缺点：无法保存最近一次快照之后的数据。
• AOF 优点：可读性高，适合保存增量数据，数据不易丢失。
• AOF 缺点：文件体积大，恢复时间长。

RDB-AOF 混合持久化方式

Redis 4.0 之后推出了此种持久化方式，RDB 作为全量备份，AOF 作为增量备份，并且将此种方式作为默认方式使用。

在上述两种方式中，RDB 方式是将全量数据写入 RDB 文件，这样写入的特点是文件小，恢复快，但无法保存最近一次快照之后的数据，AOF 则将 Redis 指令存入文件中，这样又会造成文件体积大，恢复时间长等弱点。

在 RDB-AOF 方式下，持久化策略首先将缓存中数据以 RDB 方式全量写入文件，再将写入后新增的数据以 AOF 的方式追加在 RDB 数据的后面，在下一次做 RDB 持久化的时候将 AOF 的数据重新以 RDB 的形式写入文件。

这种方式既可以提高读写和恢复效率，也可以减少文件大小，同时可以保证数据的完整性。

在此种策略的持久化过程中，子进程会通过管道从父进程读取增量数据，在以 RDB 格式保存全量数据时，也会通过管道读取数据，同时不会造成管道阻塞。

可以说，在此种方式下的持久化文件，前半段是 RDB 格式的全量数据，后半段是 AOF 格式的增量数据。此种方式是目前较为推荐的一种持久化方式。

Redis 数据的恢复

RDB 和 AOF 文件共存情况下的恢复流程如下图：