标签:一个 hash queue logs src 不能 tar lis 简单
原文:redis 事务 和 watch
一般的 事务简单来说就是 一系列的操作保证原子性,成功都成功~失败都失败。
但是!但是!但是! redis
的事务在执行中出错时,错的将会被忽略,队列之后的指令依然可以执行。一旦出现这种情况 需要手动回滚。
redis 的事务仅仅保证了所有的操作都会严格的 按照原子操作来执行,不保证所有的都是成功的,这需要开发者自己来约束。
如何开启事物并开始执行
设定事务的开启位置,此指令执行后,后续的所有指令均加入到事务中。
设定事务的结束位置,同时执行事务。与multi成对出现,成对使用
加入事务的命令暂时到任务队列
中,没有立即执行,在一切顺利的情况下(在nulti 和 exec 之间没有出现error
)只有执行exec命令才开始执行。
将 multi
之后但还没有 exec
的事物取消掉
discard
终止当前事务定义,发生在multi之后,exec之前。
语法错误
在事务的定义阶段,也就是 multi
和 exec
之间存在语法错误,那么整个事务队列将会被删除。
当redis
事务开始执行,就不在乎是否全部成功,即使存在error
后面的也会执行,需要手动回滚。
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name monkey
QUEUED
127.0.0.1:6379> set gender male or female # 执行这行会报错
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> exec
1) OK # name 设置成功了
2) (error) ERR syntax error # gender 失败
3) "monkey" # 错误之后的也会执行~ 这事务 很蛋疼~~
127.0.0.1:6379>
将操作过程中被影响的数据提前备份记录
单数据:string
多数据:hash,list,set,zset
使用之前备份的数据恢复事务操作之前的数据。
单数据:直接set(注意周边属性,例如时效)
多数据:修改对应值或整体克隆复制
假如在线商城的某个货物售空了,此时有多个业务员可以进行补货操作。但是又希望在卖的商品不能超过100个,应该怎么办?
分析
这几个业务员不可能每次补货之前都沟通一下,因此必须要保证每次只能有一个人来操作数据,并且数据一旦被修改,就不需要其他人在修改了。一旦多个人同时修改,则只有一个人能修改成功。
对 key
添加监视锁,在执行exec
前如果 key
发生了变化,终止事务执行
watch key1 [key2…] # 可以同时监视多个变量
取消对所有key的监视
unwatch # 取消对所有key的监视
我们先对当前的 货物数
进行监视,对补货操作开启事务,如果在执行事务 exec
之前 数量变了,表示已经有人进行了补货操作,因此终止事务。如果一切顺利,成功的补货完成。
注意 在 watch 对象改变时,事务队列中所有的操作都不会被执行,就是说事务队列直接被销毁。
标签:一个 hash queue logs src 不能 tar lis 简单
原文地址:https://www.cnblogs.com/lonelyxmas/p/13124571.html