Redis的“假事務”與分布式鎖

關注公眾號：CoderBuff，回復“redis”獲取《Redis5.x入門教程》完整版PDF。

• 《Redis5.x入門教程》目錄
• 第一章 · 准備工作
• 第二章 · 數據類型
• 第三章 · ​命令
• 第四章 ​· 配置
• 第五章 · Java客戶端（上）
• 第六章 · 事務
• 第七章 · 分布式鎖
• 第八章 · Java客戶端（下）

第六章 · 事務

我們在學習MySQL的存儲殷勤時知道，MySQL中innodb支持事務而myisam不支持事務。而事務具有四個特性：

• 一致性
• 原子性
• 隔離性
• 持久性

在redis盡管提供了事務相關的命令，但實際上它是一個“假事務”，因為它並不支持回滾，也就是說在redis中一個事務有多個命令執行，並不能保證原子性。所以要使用redis的事務，一定要慎重。

Redis中的“假事務”（不保證原子性）

在redis中事務相關的命令一共有以下幾個：

watch [key1] [key2]：監視一個或多個key，在事務開始之前如果被監視的key有改動，則事務被打斷。

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

exec：執行事務。

discard：取消事務的執行。

unwatch：取消監視的key。

• 正常執行事務

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name kevin
QUEUED
127.0.0.1:6379> set age 25
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> set sex male
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) "kevin"
4) OK

• 取消事務執行

取消事務執行，命令將不會被執行。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name yulinfeng
QUEUED
127.0.0.1:6379> set age 26
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get name
"kevin"

• 事務中的命令出現命令性錯誤，類似Java的編譯錯誤，執行事務時，所有的命令都不會被執行。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name yulinfeng
QUEUED
127.0.0.1:6379> setget age 26
(error) ERR unknown command `setget`, with args beginning with: `age`, `26`, 
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get name
"kevin"

• 事務中出現執行時錯誤，類似Java的運行時異常，執行事務時，部分命令會被執行成功，也即是不保證原子性。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr name
QUEUED
127.0.0.1:6379> set age 26
QUEUED
127.0.0.1:6379> exec
1) (error) ERR value is not an integer or out of range
2) OK
127.0.0.1:6379> get age
"26"

• 使用watch監視key在事務之前被改動，正常未被改動時的情況，所有命令正常執行。

127.0.0.1:6379> watch name
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name yulinfeng
QUEUED
127.0.0.1:6379> set age 18
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
127.0.0.1:6379> get age
"18"

• 使用watch監視key，此時在事務執行前key被改動，事務將取消不會執行所有命令。

我們現在一個redis客戶端中執行watch命令。

127.0.0.1:6379> watch name
OK

此時我們打開另一個redis客戶端，修改key=name的值。

127.0.0.1:6379> set name kevin
OK

我們再次回到第一個客戶端，開始輸入事務的命令塊。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name abc
QUEUED
127.0.0.1:6379> set age 1
QUEUED
127.0.0.1:6379> exec
(nil)

可看到通過exec執行事務時，事務並沒有執行成功，而是返回“nil”。

Java中Jedis使用redis事務，則通過調用以下方法實現，具體命令可參照文檔：

@Test
public void testTransaction() {
    Jedis jedis = RedisClient.getJedis();
    jedis.watch("a", "c");
    Transaction transaction = jedis.multi();
    transaction.set("a", "b");
    transaction.set("c", "d");
    transaction.exec();
}

通過Lua腳本保證Redis的真事務

redis中自帶的事務命令，最致命的前面已經多次提到，那就是不保證原子性，所以在使用redis的事務時，一定要謹慎。

但如果我們一定要在redis中實現真正的事務應該怎么辦呢？redis為我們提供了另外一種更為“靈活”的方式——Lua腳本。

在這里當然並不會詳細講解Lua的語法規則，我們一步步來看在redis中如何執行Lua腳本，以及Lua是如何運用在redis保證事務的。

我們先用Lua腳本在redis中實現調用字符串的set命令，我們先看示例：

127.0.0.1:6379> eval "return redis.call('set', KEYS[1], ARGV[1])" 1 company bat
OK
127.0.0.1:6379> get company
"bat"

eval是執行Lua腳本的命令，第二個參數是Lua腳本，第三個參數是一個數字表示一共有多少個key，第四個參數表示key值，第五個參數表示value值，eval [lua scripts] [numskey] [key1] [key2] [value1] [value2] ……。

接下來，我們來一個Lua腳本，腳本中包含寫入name的值和age的值。

127.0.0.1:6379> eval "redis.call('set', KEYS[1], ARGV[1]) redis.call('set', KEYS[2], ARGV[2])" 2 name age kevin 25
(nil)
127.0.0.1:6379> get name
"kevin"
127.0.0.1:6379> get age
"25"

對於簡單的Lua腳本通過命令行的方式直接編輯問題不大，但如果是比較復雜得Lua腳本，通常我們會單獨寫一個Lua腳本文件，然后載入它，例如以下示例：

local exist = redis.call('exists', KEYS[1])

if exist then
    return redis.call('incr', KEYS[1])
else
    return nil
end

我們將它保存為Lua腳本文件，執行以下命令：

okevindeMacBook-Air:redis-5.0.7 okevin$ redis-cli --eval ~/Desktop/lua_test.lua view
(nil)

可以看到key=view並不存在，所以返回nil，如果此時我們在redis中定義了一個key=view的值，此時將返回以下信息：

okevindeMacBook-Air:redis-5.0.7 okevin$ redis-cli --eval ~/Desktop/lua_test.lua view
(integer) 2

Jedis中如何載入Lua腳本

有關本節的源碼：https://github.com/yu-linfeng/redis5.x_tutorial/tree/master/code/jedis

在Jedis可以直接調用Jedis類的eval方法，第一個參數是Lua腳本，第二個參數是key值，第三個參數是value值。

public void testLua() {
    Jedis jedis = RedisClient.getJedis();
    List<String> keys = new ArrayList<>();
    keys.add("name");
    keys.add("age");
    List<String> values = new ArrayList<>();
    values.add("kevin");
    values.add("25");
    jedis.eval("redis.call('set', KEYS[1], ARGV[1]) redis.call('set', KEYS[2], ARGV[2])", keys, values);
    jedis.close();
}

第七章 · 分布式鎖

redis在我們日常開發中，除了用來做緩存提高應用程序的性能，降低數據庫壓力之外。可能用途最廣泛地當屬用redis來做分布式鎖了。

在單機中，我們要解決並發時線程安全的問題會使用JDK的synchronized或者Lock類，或者直接使用線程安全的類，例如JUC（java.util.concurrent並發包）。而在大型的應用程序中，單機部署顯然不能滿足我們的需求，這個時候要在分布式集群環境中對互斥資源進行控制訪問，就需要使用到分布式鎖。

在本章中，我們着重介紹基於redis的分布式鎖，同時將簡單介紹其他分布式鎖的解決方案。

開始之前先總結無論什么方式的分布式鎖，其核心都是如有不存在某個key則寫入，存在則返回寫入失敗。

通過redis實現分布式鎖

redis中主要通過setnx命令實現，全稱是“SET if Not eXists”，意為如果存在則寫入。如果不存在key則返回1，已經存在了這個key，則會返回0。釋放鎖時直接調用del命令刪除即可。

127.0.0.1:6379> setnx redis_lock a
(integer) 1
127.0.0.1:6379> setnx redis_lock a
(integer) 0

但是請注意，使用setnx有一定的風險，我們知道加鎖就有存在“死鎖”的可能性，而打破死鎖的方法之一就是主動釋放資源（設置鎖過期時間），然而setnx並沒有提供過期時間的設置，redis提供了另外一個命令——expire來設置key值得過期時間，所以改造上面的例子為以下所示：

127.0.0.1:6379> setnx redis_lock a			#設置一個分布式鎖的key為redis_lock
(integer) 1
127.0.0.1:6379> expire redis_lock 5			#設置redis_lock的過期時間為5秒，到期自動刪除
(integer) 1
127.0.0.1:6379> setnx redis_lock a			#此時再設置分布式鎖的key為redis_lock，返回0失敗
(integer) 0
127.0.0.1:6379> setnx redis_lock a			#過5秒再設置分布式鎖的key為redis_lock，返回1成功
(integer) 1

可以看到通過組合setnx和expire命令，能達到我們想要的結果。但是請注意，它仍然存在一個問題，那就是這兩個命令並不是原子性的，如果在執行expire redis_lock 5時，redis服務恰好宕機，此時這個key將會一直存在。

好在redis為我們提供了set命令的分布式用法並且可以設置為過期時間，關鍵是原子性的。官方的命令參數為set key value [expiration EX seconds|PX milliseconds] [NX|XX]。

[expiration EX seconds|PX milliseconds]參數EX表示過期時間單位為“秒”，PX表示過期時間單位為“毫秒”。

[NX|XX]參數NX表示“SET if Not eXists”不存在則寫入，XX表示“SET if eXists”存在則寫入，分布式鎖的場景中使用“NX”參數。

所以我們設置一個key值名為“lock”的鎖，5秒后自動刪除：

127.0.0.1:6379> set lock a ex 5 nx			#設置一個key值名為“lock”的鎖，5秒后自動刪除
OK
127.0.0.1:6379> set lock a ex 5 nx			#5秒內設置一個key值名為“lock”的鎖，5秒后自動刪除。返回nil失敗
(nil)
127.0.0.1:6379> set lock a ex 5 nx			#5秒后設置一個key值名為“lock”的鎖，5秒后自動刪除。返OK成功
OK

使用redis作為分布式鎖，最好要設置過期時間，也就是最好使用set命令。

其他分布式鎖

通過ZooKeeper實現分布式鎖

ZooKeeper是一個分布式協調服務中間件，它可以用作注冊中心、動態配置中心等等。

我們利用ZooKeeper的臨時有序節點也可以實現分布式鎖。

ZooKeeper的數據結構類似Linux中的文件結構，總體來講它時“一棵樹”，節點中記錄相關信息。節點分為“永久節點”和“臨時節點”。當我們要獲取一個鎖時，需要在ZooKeeper的結構中創建一個臨時有序節點，釋放鎖同樣時刪除節點。獲取分布式鎖，即獲取一個ZooKeeper的臨時有序節點，如果獲取到的有序節點存在比序號比自己更小的兄弟節點，即獲取鎖失敗。

基於ZooKeeper實現分布式鎖可以利用ZooKeeper監聽的特性，一旦有節點發生變化可以進行通知。這點是Redis不具備的。但由於它的實現方式是創建和刪除節點，所以在性能上不如redis。

通過MySQL實現分布式鎖

通過MySQL實現分布式鎖是我以前遇到的一個面試問題，思考以下實現方式：

在MySQL創建一個有關鎖的表“tb_lock”，一共有兩列，一列叫“key”並設置為唯一索引，另一列設置為“value”。

獲取鎖時，通過insert插入一條記錄，如果插入成功則獲取鎖成功；插入失敗則獲取鎖失敗。

一聽，是不是覺得有點意思，好像確實能通過MySQL來實現分布式鎖，這樣我們就不必引入redis或ZooKeeper。那為什么我們日常開發中幾乎沒有人這樣用過呢？實際上，MySQL實現分布式鎖，它僅僅滿足了控制互斥資源這一點，盡管它是最核心的，但分布式鎖不僅是控制互斥資源，它還需要具備以下特性：

• 可設置過期時間，防止死鎖
• 需要具備阻塞獲取鎖的特性
• 較高的性能和可靠性
• 鎖還需要可重入
• ……

所以如果要使用MySQL來實現分布式鎖，你需要去解決以上的問題，對於成熟的redis和ZooKeeper分布式鎖方案，我們大可不必再造一個不可靠的輪子。

關注公眾號：CoderBuff，回復“redis”獲取《Redis5.x入門教程》完整版PDF。

這是一個能給程序員加buff的公眾號 （CoderBuff）