redis事务,分布式锁

事务:一组命令集合

主要命令multi 和exec

multi
set a 1
sadd s1 a
......
exec

错误处理

  • (1)语法错误
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set a 1
QUEUED
127.0.0.1:6379> set b
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> seta c
(error) ERR unknown command 'seta'
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get a
(nil)
127.0.0.1:6379> 

只要有任何一个语法错误,正确的也不会执行

  • (2)运行错误
    比如a是string类型,然后按照hash操作 hset a k1 v1
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set a 1
OK
127.0.0.1:6379> type a
string
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set n 1
QUEUED
127.0.0.1:6379> hset a k1 v1
QUEUED
127.0.0.1:6379> set m 2
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> mget n m
1) "1"
2) "2"
127.0.0.1:6379> type a
string

正确的指令是被执行了,redis事务不支持回滚,所以需要开发者自己处理
开发中规范键名,一般不会出现这种问题

DISCARD取消事务

分布式锁

setnx a:lock 1
expire a:lock 5
del a:lock
为了使setnx和expire能一起执行,而expire的执行又依赖setnx是否成功,显然放事务里是不成立的

setnx和expire组合在一起的原子指令

set a:lock 1 ex 10 nx


以上是这只a:lock 为1 有效期为10s的原子操作

超时问题

Redis 的分布式锁不能解决超时问题,如果在加锁和释放锁之间的逻辑执行的太长,以至于超出了锁的超时限制,就会出现问题。因为这时候第一个线程持有的锁过期了,临界区的逻辑还没有执行完,这个时候第二个线程就提前重新持有了这把锁,导致临界区代码不能得到严格的串行执行。

为了避免这个问题,Redis 分布式锁不要用于较长时间的任务。如果真的偶尔出现了,数据出现的小波错乱可能需要人工介入解决

posted @ 2019-03-10 23:15 H&K 阅读(...) 评论(...) 编辑 收藏