redis 交易處理

標籤：上下文   監控   

 redis對事務的處理目前還非常簡單，Redis只能保證一個client發起的事務中的命令可以連續的執行，而中間不會插入其他client的命令，當一個client在一個串連中發出multi命令的時候，這個串連會進入一個事務上下文，該串連後續的命令不會立即執行，而是先放到一個隊列中，當執行exec命令時，redis會順序執行隊列中的所有命令。

 multi 標記一個事務塊的開始。

 set name zhangdh

 set age 30

 exec  提交

 multi

 incr age

 incr name

 exec 第一個執行成功，第二個會報錯。

 這也是redis事務需要改進的地方。

 discard 復原，取消事務，放棄執行事務塊裡面的所有命令。清空事務的命令隊列，並退出事務上下文。

 在Redis的事務中，WATCH命令可用於提供CAS(check-and-set)功能。假設我們通過WATCH命令在事務執行之前監控了多個Keys，倘若在WATCH之後有任何Key的值發生了變化，EXEC命令執行的事務都將被放棄，同時返回Null multi-bulk應答以通知調用者事務執行失敗。例如，我們再次假設Redis中並未提供incr命令來完成索引值的原子性遞增，如果要實現該功能，我們只能自行編寫相應的代碼。其偽碼如下：

      val = GET mykey

      val = val + 1

      SET mykey $val

      以上代碼只有在單串連的情況下才可以保證執行結果是正確的，因為如果在同一時刻有多個用戶端在同時執行該段代碼，那麼就會出現多線程程式中經常出現的一種錯誤情境--競態爭用(race condition)。比如，用戶端A和B都在同一時刻讀取了mykey的原有值，假設該值為10，此後兩個用戶端又均將該值加一後set回Redis伺服器，這樣就會導致mykey的結果為11，而不是我們認為的12。為瞭解決類似的問題，我們需要藉助WATCH命令的協助，見如下代碼：

      WATCH mykey

      val = GET mykey

      val = val + 1

      MULTI

      SET mykey $val

      EXEC

      和此前代碼不同的是，新代碼在擷取mykey的值之前先通過WATCH命令監控了該鍵，此後又將set命令包圍在事務中，這樣就可以有效保證每個串連在執行EXEC之前，如果當前串連擷取的mykey的值被其它串連的用戶端修改，那麼當前串連的EXEC命令將執行失敗。這樣調用者在判斷傳回值後就可以獲悉val是否被重新設定成功。

      watch name 

      set name zjz

      multi

      set name zby

      exec 此事務會失敗。輸出name值為zjz

redis 交易處理