Redis中发布订阅及事务的知识点整理

共计 3443 个字符，预计需要花费 9 分钟才能阅读完成。

这篇文章主要讲解了“Redis 中发布订阅及事务的知识点整理”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“Redis 中发布订阅及事务的知识点整理”吧！

一、Redis 发布订阅

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。

打开两个窗口：session1 和 session2

在 session1 中订阅消息：

subscribe xbqChannel 客户端订阅消息，xbqChannel 为相应的频道

在 session2 中发布消息：

publish xbqChannel testMessge 发布消息，同时订阅该频道的客户端能收到该消息

二、Redis 事务

和众多其它数据库一样，Redis 作为 NoSQL 数据库也同样提供了事务机制。在 Redis 中，MULTI/EXEC/DISCARD/WATCH 这四个命令是我们实现事务的基石。

Redis 事务带有以下重要的特征：

在事务中的所有命令都将会被串行化的顺序执行，事务执行期间，Redis 不会再为其它客户端的请求提供任何服务，从而保证了事物中的所有命令被原子的执行。

和关系型数据库中的事务相比，在 Redis 事务中如果有某一条命令执行失败，其后的命令仍然会被继续执行。

我们可以通过 MULTI 命令开启一个事务，有关系型数据库开发经验的人可以将其理解为 BEGIN   TRANSACTION 语句。在该语句之后执行的命令都将被视为事务之内的操作，最后我们可以通过执行 EXEC/DISCARD 命令来提交 / 回滚该事务内的所有操作。这两个 Redis 命令可被视为等同于关系型数据库中的 COMMIT/ROLLBACK 语句。

在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行 EXEC 命令之后，那么该事务中的所有命令都会被服务器执行。

当使用 Append-Only 模式时，Redis 会通过调用系统函数 write 将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失。Redis 服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用 Redis 工具包中提供的 redis-check-aof 工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动 Redis 服务器了。

一个事务从开始到执行会经历以下三个阶段：开始事务、命令入队、执行事务。

三、安全

1. 查看 redis 的密码：config get requirepass

2. 为 redis 设置密码的方法：

在 redis.conf 中进行配置：requirepass xbqpass

通过命令行进行设置：redis config set requirepass xbqpass

3. 当对 redis 进行操作时，需要授权：redis auth xbqpass

四、持久化 1、RDB（Snapshotting 快照持久化）

快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中, 默认的文件名为 dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置 redis 在 n 秒内如果超过 m 个 key 被修改就自动做快照，下面是默认的快照保存配置：

鸿蒙官方战略合作共建——HarmonyOS 技术社区

save 900 1 #900 秒内如果超过 1 个 key 被修改，则发起快照保存

save 300 10 #300 秒内容如超过 10 个 key 被修改，则发起快照保存

save 60 10000 #在 60 秒 (1 分钟) 之后，如果至少有 10000 个 key 发生变化，则 dump 内存快照

client   也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘 io 操作，可能会严重影响性能。另外由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。

2、AOF（Append-only）

redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认是 appendonly.aof)。当 redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

鸿蒙官方战略合作共建——HarmonyOS 技术社区

appendonly yes #启用 aof 持久化方式

# appendfsync always #每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用

appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐

# appendfsync no #完全依赖 os，性能最好, 持久化没保证

3、RDB 机制的优势和劣势：

1.RDB 优势:

一旦采用该方式，那么整个 Redis 数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近 24 小时的数据，同时还要每天归档一次最近 30 天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

对于灾难恢复而言，RDB 是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

性能最大化。对于 Redis 的服务进程而言，在开始持久化时，它唯一需要做的只是 fork 出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行 IO 操作了。

相比于 AOF 机制，如果数据集很大，RDB 的启动效率会更高。

2.RDB 劣势：

如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么 RDB 将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

由于 RDB 是通过 fork 子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是 1 秒钟。

4、AOF 机制的优势和劣势：

1.AOF 优势：

1).   该机制可以带来更高的数据安全性，即数据持久性。Redis 中提供了 3 中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。

2).   由于该机制对日志文件的写入操作采用的是 append 模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在 Redis 下一次启动之前，我们可以通过 redis-check-aof 工具来帮助我们解决数据一致性的问题。

3).   如果日志过大，Redis 可以自动启用 rewrite 机制。即 Redis 以 append 模式不断的将修改数据写入到老的磁盘文件中，同时 Redis 还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行 rewrite 切换时可以更好的保证数据安全性。

4). AOF 包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

2.AOF 劣势：

对于相同数量的数据集而言，AOF 文件通常要大于 RDB 文件。根据同步策略的不同，AOF 在运行效率上往往会慢于 RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和 RDB 一样高效。

3. 如何修复坏损的 AOF 文件：

1). 将现有已经坏损的 AOF 文件额外拷贝出来一份。 

2). 执行 redis-check-aof –fix 命令来修复坏损的 AOF 文件。 

3). 用修复后的 AOF 文件重新启动 Redis 服务器。

感谢各位的阅读，以上就是“Redis 中发布订阅及事务的知识点整理”的内容了，经过本文的学习后，相信大家对 Redis 中发布订阅及事务的知识点整理这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！