Redis的「假事務」與分佈式鎖
關注公衆號：CoderBuff，回覆「redis」獲取《Redis5.x入門教程》完整版PDF。html
- 《Redis5.x入門教程》目錄
- 第一章 · 準備工做
- 第二章 · 數據類型
- 第三章 · 命令
- 第四章 · 配置
- 第五章 · Java客戶端（上）
- 第六章 · 事務
- 第七章 · 分佈式鎖
- 第八章 · Java客戶端（下）
第六章 · 事務
咱們在學習MySQL的存儲殷勤時知道，MySQL中innodb支持事務而myisam不支持事務。而事務具備四個特性：java
- 一致性
- 原子性
- 隔離性
- 持久性
在redis儘管提供了事務相關的命令，但實際上它是一個「假事務」，由於它並不支持回滾，也就是說在redis中一個事務有多個命令執行，並不能保證原子性。因此要使用redis的事務，必定要慎重。git
Redis中的「假事務」（不保證原子性）
在redis中事務相關的命令一共有如下幾個：程序員
watch [key1] [key2]：監視一個或多個key，在事務開始以前若是被監視的key有改動，則事務被打斷。github
multi：標記一個事務的開始。面試
exec：執行事務。redis
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。
<div align="center">這是一個能給程序員加buff的公衆號 （CoderBuff）</div> <div align="center"><img src="https://img2018.cnblogs.com/blog/630246/201907/630246-20190717223740465-1981496921.png" /></div>
- 1. Redis的「假事務」與分佈式鎖
- 2. redis事務,分佈式鎖
- 3. Redis事務、分佈式鎖
- 4. 分佈式事務假死鎖
- 5. 分佈式事務與分佈式鎖
- 6. 分佈式鎖與事務
- 7. Redis~分佈式事務和分佈式事務鎖
- 8. Redis事務機制和分佈式鎖
- 9. redis事務和分佈式鎖
- 10. Redis事務和分佈式鎖
- 更多相關文章...
- • Redis發佈訂閱模式 - Redis教程
- • 探索Redis事務回滾 - Redis教程
- • 常用的分佈式事務解決方案
- • 再有人問你分佈式事務，把這篇扔給他
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Redis的「假事務」與分佈式鎖
- 2. redis事務,分佈式鎖
- 3. Redis事務、分佈式鎖
- 4. 分佈式事務假死鎖
- 5. 分佈式事務與分佈式鎖
- 6. 分佈式鎖與事務
- 7. Redis~分佈式事務和分佈式事務鎖
- 8. Redis事務機制和分佈式鎖
- 9. redis事務和分佈式鎖
- 10. Redis事務和分佈式鎖