讲解Redis发布订阅演示、事务演示、持久化

推荐（免费）：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发布订阅演示、事务演示、持久化的详细内容，更多请关注gxlcms其它相关文章！