redis事务及锁应用、发布订阅模式
2016-11-23 19:10
435 查看
事务
mysql和ridis事务对比:redis事务时执行命令放到了队列里。
注:rollback与discard的区别
如果已经成功执行了2条语句,第三条语句出错
rollback后前2条语句影响消失。
discard只是结束本次事务,前2句造成的影响还在。
注:在multi后面的语句中,语句出错可能有2中情况
1.语法就有问题
这种exec时,所有语句都得不到执行
2.语法没错,但使用对象有问题,比如zadd操作list对象。exec之后,会执行正确的语句,并跳过有不适当的语句。
watch监控key
watch命令会监视给定的key,当exec时候如果监视的key从调用watch后发生过变化,则整个事务会失败。也可以调用watch多次监视多个key.这
样就可以对指定的key加乐观锁了。注意watch的key是对整个连接有效的,事务也一样。如果连接断开,监视和事务都会被自动清除。当然了exec,discard,unwatch命令都会清除连接中的所有监视。
be
用法:
watch key1 key2 ... keyN
作用监听key1 key2 keyN有没有变化,如果有变化,则事务取消
例如:
客户端1:设置了watch一张票的数目,然后开启multi事务,当他在执行exec前,客户端2买了这张票,exec会执行失败。
unwatch
取消所有watch监听
乐观锁和悲观锁区别:(转自:http://blog.csdn.net/hongchangfirst/article/details/26004335
悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。
模式:
publish----->频道-----》subscribe
下面的channel代表频道名:
publish channel 内容 --发布新闻内容
subscribe channel 内容 --订阅新闻频道
适宜做在线聊天,消息推送
注意:
1.如果先发布,客户端未此时未订阅,之后客户端订阅不会显示之前发布的消息。
psubscribe channel* 凡是channel开头的频道,全部监听
相关文章推荐
- Redis基础学习--Redis 事务(watch命令)、生存时间、排序、消息通知("发布/订阅"模式)、管道、节省空间
- Redis订阅和发布模式和Redis事务
- Redis的高级应用-事务处理、持久化、发布与订阅消息、虚拟内存使用
- 基于spring-redis发布订阅模式的实现
- Redis入门系列之队列和发布订阅模式
- 小贝_redis高级应用-发布与订阅
- Redis发布订阅模式
- Redis研究(十六)—发布/订阅模式
- Redis事务、锁应用、消息订阅
- redis之发布与订阅(publish/subscribe模式)
- Redis - 发布/订阅模式
- 基于订阅/发布模式的简易聊天室实现(java+redis)
- redis 高级应用之二(Redis的持久化 和 消息的[pub/sub]发布和订阅)
- redis的发布/订阅模式
- Redis发布与订阅模式
- redis的发布订阅模式
- 011 redis的“发布/订阅”模式&redis的排队
- 基于topic的发布/订阅模式在UI程序中的应用
- redis 由浅入深 之进阶(发布与订阅、事务、连接和Reids服务器)
- Redis源码分析(三十)--- pubsub发布订阅模式