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 分布式锁不要用于较长时间的任务。若是真的偶尔出现了，数据出现的小波错乱可能须要人工介入解决