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 分佈式鎖不要用於較長時間的任務。若是真的偶爾出現了，數據出現的小波錯亂可能須要人工介入解決