本文主要是介绍Redis事务,管道,发布订阅，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Redis事务
redis事务本质上是一组命令的集合,按照顺序串行化执行命令而不被其他命令打断
redis事务开启后将要执行的命令放到事务队列中,提交事务后一次性顺序排他地执行所有命令
关键词:单线程,无隔离级别,不保证原子性,排他性,顺序性
要注意和mysql的acid进行区分
怎么用
multi--开启事务
exec--提交事务
discard--放弃提交事务
watch,unwatch--监视/取消监视某个键
redis事务执行遵循的规则总结起来就是:语法错误全体连坐,个别出错冤头债主
- 提交事务时系统检查到命令有语法出错,则整个事务都无法提交
- 命令没有检查出错误,但是执行的对象不合理则该命令执行失败,其他命令照常执行
redis通过watch实现乐观锁:
如果watch监视的key在事务提交前被修改了,那么整个事务都将执行失败
一旦执行了exec之前加的监控锁都会被取消,当客户端断开连接时所有key都会被取消监视
Redis管道
管道(pipeline)是为了解决执行大量命令时要频繁进行网络通信和系统I/O影响性能的问题
通过管道可以将多条命令一次性传输给服务端,服务端再进行统一回复
管道和原生批量命令对比
- 原生批量命令(如mset...)是原子性的,管道执行的命令是非原子性的
- 管道支持批量执行不同命令,原生批量命令一次只支持一种
- 管道需要C/S共同完成
管道和事务对比
- 事务具有原子性,管道不具有原子性
- 管道一次性将多条命令发送到服务器,事务是一条一条的发
- 执行事务会阻塞其他命令执行,执行管道的命令时不会
使用管道时不要使用太多的数据,因为服务端会被强制去处理管道中的命令,而客户端也会进入阻塞状态,所以一次不要传太多命令
Redis发布订阅
redis的发布订阅功能有点类似于我们的消息队列mq,客户端可以订阅不同的频道,当该频道发出消息时会自动转发给订阅的客户
关键词:非持久化,不保证消息签收,实时性高
常用命令
psubscribe是按照模式批量订阅,通过给定模式(*,?等)订阅频道
替代发布订阅
实际生产中不常使用发布订阅,为解决消息无法持久化,无法保证消息到达等问题,我们可以使用redis的stream数据结构或者引入其他消息中间件来代替
这篇关于Redis事务,管道,发布订阅的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
