推荐(免费):redis教程
文章目录
一、Redis发布订阅介绍
Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。Redis 客户端可以订阅任意数量的频道。
应用场景:
构建实时消息系统
,比如普通的即时聊天,群聊等功能。推送消息
给粉丝们。微信公众号模式
。二、Redis发布订阅演示
发布订阅语法
订阅频道:
subscribe channel1 [channel2 ...]
订阅给定的一个或多个频道的信息
psubscribe pattern1 [pattern2 ...]
订阅一个或多个符合给定模式的频道。
发布频道:
publish channel message
将信息发送到指定的频道。
退订频道:
unsubscribe channel1 [ channel2 ...]
指退订给定的频道。
punsubscribe pattern1 [pattern2 ...]
退订所有给定模式的频道。
三、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
命令触发事务。
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文件中)。
优点:
缺点:
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发布订阅演示、事务演示、持久化的详细内容,更多请关注php中文网其它相关文章!
已抢186504个
抢已抢67281个
抢已抢352978个
抢已抢667161个
抢已抢122323个
抢已抢23438个
抢