共计 2378 个字符，预计需要花费 6 分钟才能阅读完成。
自动写代码机器人，免费开通
丸趣 TV 小编给大家分享一下 Redis 发布订阅演示、事务演示、持久化的方法，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
文章目录
一、Redis 发布订阅介绍
二、Redis 发布订阅演示
三、Redis 中的事务
四、转账功能 -Redis 事务演示
五、转账功能升级版 -watch
六、事务的错误处理
业务逻辑错误
语法错误
七、Redis 持久化
RDB 持久化
AOF 持久化
一、Redis 发布订阅介绍
Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。Redis 客户端可以订阅任意数量的频道。
应用场景：
①构建实时消息系统，比如普通的即时聊天，群聊等功能。
②在一个博客网站中，有 n 多个粉丝订阅了你，当你发布新文章，就可以推送消息给粉丝们。
③微信公众号模式。
二、Redis 发布订阅演示
发布订阅语法
订阅频道：
subscribe channel1 [channel2 …] 订阅给定的一个或多个频道的信息
psubscribe pattern1 [pattern2 …] 订阅一个或多个符合给定模式的频道。
发布频道：
publish channel message 将信息发送到指定的频道。
退订频道：
unsubscribe channel1 [channel2 …] 指退订给定的频道。
punsubscribe pattern1 [pattern2 …] 退订所有给定模式的频道。
三、Redis 中的事务
Redis 事务可以一次执行多个命令，（按顺序地串行化执行，执行中不会被其它命令插入，不许加塞）
事务应用场景：
商品秒杀
转账
两个特点：
Redis 会将一个事务中的所有命令序列化，然后按顺序执行(任意命令执行失败，其余的命令依然被执行)
执行中不会被其它命令插入，不许出现加赛行为。
一个事务从开始到执行会经历以下三个阶段：开始事务、命令入队、执行事务。
事务相关命令:
multi 标记一个事务块的开始。
exec 执行所有事务块内的命令。
discard 取消事务，放弃执行事务块内的所有命令。
watch key 监视一个(或多个)key，如果在事务执行之前这个(或这些)key 被其他命令所改动，那么事务将被打断。
unwatch 取消 watch 命令对所有 key 的监视。
四、转账功能 -Redis 事务演示
需求：转帐功能，A 向 B 帐号转帐 50 元。
转账前 A 有 80 元，B 有 10 元。
转账后 A 有 30 元，B 有 60 元。
本例先以 multi 开始一个事务，然后将多个命令入队到事务中，最后由 exec 命令触发事务。
输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行。
直到输入 Exec 后，Redis 会将之前的命令队列中的命令依次执行。
执行 exec 前，如果发现添加的命令有问题，可以使用 discard 命令放弃队列运行，类似于 MySQL 中的回滚操作。
五、转账功能升级版 -watch
需求：某一账户在一事务内进行操作，在提交事务前，另一个进程对该账户进行操作。
上文中的转账是不安全的，在执行中如果有其他命令对账户 a 或者 b 的操作，可能会出现幻读；解决办法是添加 watch 命令，可以对账户进行 watch 监视，一旦在事务执行中，出现了其他命令对账户 a 或 b 操作，程序直接报错回滚。
执行了 watch 命令后，如果 exec 或 discard 命令先被执行，就不需要再执行 unwatch 来取消对 key 的监视了，因为 exec 或 discard 命令会自动取消监视。
六、事务的错误处理
业务逻辑错误
发生业务逻辑错误：只有报错的命令不会被执行，而其它的命令都会执行，不会回滚。
语法错误
发生语法错误：执行时整个的所有队列都会被取消。
七、Redis 持久化
数据存放在内存：高效、但断电内存数据会丢失。
数据存放在硬盘：读写速度慢于内存、但断电数据不会丢失。
RDB 持久化
RDB 是 redis 的默认持久化机制。RDB 相当于照快照，保存的是数据的一种状态。(几十 G 的数据可以保存为几 KB 的快照)
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为 dump.rdb(存在 redis.conf 文件中)。
优点：
快照保存数据极快、还原数据极快
适用于灾难备份
缺点：
小内存机器不适合使用，RDB 机制符合要求就会照快照，占内存。
AOF 持久化
由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外宕机，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用 AOF(Append-Only File)持久化方式。
appendonly yes 命令可以启用 AOF 持久化方式。
有三种方式如下（默认是：每秒 fsync 一次）
appendfsync always 收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
appendfsync everysec 每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中
appendfsync no 完全依赖 OS，性能最好，但持久化没保证
优点：
AOF 比快照方式有更好的持久化性，是由于在使用 AOF 持久化方式时：redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认是 appendonly.aof)。当 redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
缺点：
AOF 的方式也同时带来了另一个问题。持久化文件会变的越来越大，占硬盘。例如我们调用 incr test 命令 100 次，文件中必须保存全部的 100 条命令，其实有 99 条都是多余的。
以上是“Redis 发布订阅演示、事务演示、持久化的方法”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
向 AI 问一下细节
