面試官：Redis的事務(wù)滿足原子性嗎？

談起數(shù)據(jù)庫的事務(wù)來，估計(jì)很多同學(xué)的第一反應(yīng)都是ACID，而排在ACID中首位的A原子性，要求一個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不完成。熟悉redis的同學(xué)肯定知道，在redis中也存在事務(wù)，那么它的事務(wù)也滿足原子性嗎？下面我們就來一探究竟。

什么是Redis事務(wù)？

和數(shù)據(jù)庫事務(wù)類似，redis事務(wù)也是用來一次性地執(zhí)行多條命令。使用起來也很簡單，可以用MULTI開啟一個(gè)事務(wù)，然后將多個(gè)命令入隊(duì)到事務(wù)的隊(duì)列中，最后由EXEC命令觸發(fā)事務(wù)，執(zhí)行事務(wù)中的所有命令?？匆粋€(gè)簡單的事務(wù)執(zhí)行例子：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name Hydra
QUEUED
127.0.0.1:6379> set age 18
QUEUED
127.0.0.1:6379> incr age
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (integer) 19

可以看到，在指令和操作數(shù)的數(shù)據(jù)類型等都正常的情況下，輸入EXEC后所有命令被執(zhí)行成功。

Redis事務(wù)滿足原子性嗎？

如果要驗(yàn)證redis事務(wù)是否滿足原子性，那么需要在redis事務(wù)執(zhí)行發(fā)生異常的情況下進(jìn)行，下面我們分兩種不同類型的錯(cuò)誤分別測試。

語法錯(cuò)誤

首先測試命令中有語法錯(cuò)誤的情況，這種情況多為命令的參數(shù)個(gè)數(shù)不正確或輸入的命令本身存在錯(cuò)誤。下面我們在事務(wù)中輸入一個(gè)存在格式錯(cuò)誤的命令，開啟事務(wù)并依次輸入下面的命令：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name Hydra
QUEUED
127.0.0.1:6379> incr
(error) ERR wrong number of arguments for 'incr' command
127.0.0.1:6379> set age 18
QUEUED

輸入的命令incr后面沒有添加參數(shù)，屬于命令格式不對的語法錯(cuò)誤，這時(shí)在命令入隊(duì)時(shí)就會立刻檢測出錯(cuò)誤并提示error。使用exec執(zhí)行事務(wù)，查看結(jié)果輸出：

127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.

在這種情況下，只要事務(wù)中的一條命令有語法錯(cuò)誤，在執(zhí)行exec后就會直接返回錯(cuò)誤，包括語法正確的命令在內(nèi)的所有命令都不會被執(zhí)行。對此進(jìn)行驗(yàn)證，看一下在事務(wù)中其他指令執(zhí)行情況，查看set命令的執(zhí)行結(jié)果，全部為空，說明指令沒有被執(zhí)行。

127.0.0.1:6379> get name
(nil)
127.0.0.1:6379> get age
(nil)

此外，如果存在命令本身拼寫錯(cuò)誤、或輸入了一個(gè)不存在的命令等情況，也屬于語法錯(cuò)誤的情況，執(zhí)行事務(wù)時(shí)會直接報(bào)錯(cuò)。

運(yùn)行錯(cuò)誤

運(yùn)行錯(cuò)誤是指輸入的指令格式正確，但是在命令執(zhí)行期間出現(xiàn)的錯(cuò)誤，典型場景是當(dāng)輸入?yún)?shù)的數(shù)據(jù)類型不符合命令的參數(shù)要求時(shí)，就會發(fā)生運(yùn)行錯(cuò)誤。例如下面的例子中，對一個(gè)string類型的值執(zhí)行列表的操作，報(bào)錯(cuò)如下：

127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> lpush key1 value2
(error) WRONGTYPE Operation against a key holding the wrong kind of value

這種錯(cuò)誤在redis實(shí)際執(zhí)行指令前是無法被發(fā)現(xiàn)的，只能當(dāng)真正執(zhí)行才能夠被發(fā)現(xiàn)，因此這樣的命令是可以被事務(wù)隊(duì)列接收的，不會和上面的語法錯(cuò)誤一樣立即報(bào)錯(cuò)。

具體看一下當(dāng)事務(wù)中存在運(yùn)行錯(cuò)誤的情況，在下面的事務(wù)中，嘗試對string類型數(shù)據(jù)進(jìn)行incr自增操作：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name Hydra
QUEUED
127.0.0.1:6379> set age eighteen
QUEUED
127.0.0.1:6379> incr age
QUEUED
127.0.0.1:6379> del name
QUEUED

redis一直到這里都沒有提示存在錯(cuò)誤，執(zhí)行exec看一下結(jié)果輸出：

127.0.0.1:6379> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
4) (integer) 1

運(yùn)行結(jié)果可以看到，雖然incr age這條命令出現(xiàn)了錯(cuò)誤，但是它前后的命令都正常執(zhí)行了，再看一下這些key對應(yīng)的值，確實(shí)證明了其余指令都執(zhí)行成功：

127.0.0.1:6379> get name
(nil)
127.0.0.1:6379> get age
"eighteen"

階段性結(jié)論

對上面的事務(wù)的運(yùn)行結(jié)果進(jìn)行一下分析：

• 存在語法錯(cuò)誤的情況下，所有命令都不會執(zhí)行

• 存在運(yùn)行錯(cuò)誤的情況下，除執(zhí)行中出現(xiàn)錯(cuò)誤的命令外，其他命令都能正常執(zhí)行

通過分析我們知道了redis中的事務(wù)是不滿足原子性的，在運(yùn)行錯(cuò)誤的情況下，并沒有提供類似數(shù)據(jù)庫中的回滾功能。那么為什么redis不支持回滾呢，官方文檔給出了說明，大意如下：

• redis命令失敗只會發(fā)生在語法錯(cuò)誤或數(shù)據(jù)類型錯(cuò)誤的情況，這一結(jié)果都是由編程過程中的錯(cuò)誤導(dǎo)致，這種情況應(yīng)該在開發(fā)環(huán)境中檢測出來，而不是生產(chǎn)環(huán)境

• 不使用回滾，能使redis內(nèi)部設(shè)計(jì)更簡單，速度更快

• 回滾不能避免編程邏輯中的錯(cuò)誤，如果想要將一個(gè)鍵的值增加2卻只增加了1，這種情況即使提供回滾也無法提供幫助

基于以上原因，redis官方選擇了更簡單、更快的方法，不支持錯(cuò)誤回滾。這樣的話，如果在我們的業(yè)務(wù)場景中需要保證原子性，那么就要求了開發(fā)者通過其他手段保證命令全部執(zhí)行成功或失敗，例如在執(zhí)行命令前進(jìn)行參數(shù)類型的校驗(yàn)，或在事務(wù)執(zhí)行出現(xiàn)錯(cuò)誤時(shí)及時(shí)做事務(wù)補(bǔ)償。

提到其他方式，相信很多小伙伴都聽說使用Lua腳本來保證操作的原子性，例如在分布式鎖中通常使用的就是Lua腳本，那么，神奇的Lua腳本真的能保證原子性嗎？

簡單的Lua腳本入門

在驗(yàn)證lua腳本的原子性之前，我們需要對它做一個(gè)簡單的了解。redis從2.6版本開始支持執(zhí)行l(wèi)ua腳本，它的功能和事務(wù)非常類似，一段lua腳本被視作一條命令執(zhí)行，這樣將多條redis命令寫入lua，即可實(shí)現(xiàn)類似事務(wù)的執(zhí)行結(jié)果。我們先看一下下面幾個(gè)常用的命令。

EVAL 命令

最常用的EVAL用于執(zhí)行一段腳本，它的命令的格式如下：

EVAL script numkeys key [key ...] arg [arg ...] 

簡單解釋一下其中的參數(shù)：

• script是一段lua腳本程序

• numkeys指定后續(xù)參數(shù)有幾個(gè)key，如沒有key則為0

• key [key …]表示腳本中用到的redis中的鍵，在lua腳本中通過KEYS[i]的形式獲取

• arg [arg …]表示附加參數(shù)，在lua腳本中通過ARGV[i]獲取

看一個(gè)簡單的例子：

127.0.0.1:6379> eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 value1 vauel2
1) "key1"
2) "key2"
3) "value1"
4) "vauel2"

在上面的命令中，雙引號中是lua腳本程序，后面的2表示存在兩個(gè)key，分別是key1和key2，之后的參數(shù)是附加參數(shù)value1和value2。

如果想要使用lua腳本執(zhí)行set命令，可以寫成這樣：

127.0.0.1:6379> EVAL "redis.call('SET', KEYS[1], ARGV[1]);" 1 name Hydra
(nil)

這里使用了redis內(nèi)置的lua函數(shù)redis.call來完成set命令，這里打印的執(zhí)行結(jié)果nil是因?yàn)闆]有返回值，如果不習(xí)慣的話，其實(shí)我們可以在腳本中添加return 0;的返回語句。

SCRIPT LOAD 和 EVALSHA命令

這兩個(gè)命令放在一起是因?yàn)樗鼈円话愠蓪κ褂?。先?/span>SCRIPT LOAD，它用于把腳本加載到緩存中，返回SHA1校驗(yàn)和，這時(shí)候只是緩存了命令，但是命令沒有被馬上執(zhí)行，看一個(gè)例子：

127.0.0.1:6379> SCRIPT LOAD "return redis.call('GET', KEYS[1]);"
"228d85f44a89b14a5cdb768a29c4c4d907133f56"

這里返回了一個(gè)SHA1的校驗(yàn)和，接下來就可以使用EVALSHA來執(zhí)行腳本了：

127.0.0.1:6379> EVALSHA "228d85f44a89b14a5cdb768a29c4c4d907133f56" 1 name
"Hydra"

這里使用這個(gè)SHA1值就相當(dāng)于導(dǎo)入了上面緩存的命令，在之后再拼接numkeys、key、arg等參數(shù)，命令就能夠正常執(zhí)行了。

其他命令

使用SCRIPT EXISTS命令判斷腳本是否被緩存：

127.0.0.1:6379> SCRIPT EXISTS 228d85f44a89b14a5cdb768a29c4c4d907133f56
1) (integer) 1

使用SCRIPT FLUSH命令清除redis中的lua腳本緩存：

127.0.0.1:6379> SCRIPT FLUSH
OK
127.0.0.1:6379> SCRIPT EXISTS 228d85f44a89b14a5cdb768a29c4c4d907133f56
1) (integer) 0

可以看到，執(zhí)行了SCRIPT FLUSH后，再次通過SHA1值查看腳本時(shí)已經(jīng)不存在。最后，還可以使用SCRIPT KILL命令殺死當(dāng)前正在運(yùn)行的 lua 腳本，但是只有當(dāng)腳本沒有執(zhí)行寫操作時(shí)才會生效。

從這些操作看來，lua腳本具有下面的優(yōu)點(diǎn)：

• 多次網(wǎng)絡(luò)請求可以在一次請求中完成，減少網(wǎng)絡(luò)開銷，減少了網(wǎng)絡(luò)延遲

• 客戶端發(fā)送的腳本會存在redis中，其他客戶端可以復(fù)用這一腳本，而不需要再重復(fù)編碼完成相同的邏輯

Java代碼中使用lua腳本

在Java代碼中可以使用Jedis中封裝好的API來執(zhí)行l(wèi)ua腳本，下面是一個(gè)使用Jedis執(zhí)行l(wèi)ua腳本的例子：

public static void main(String[] args) {
    Jedis jedis = new Jedis("127.0.0.1", 6379);
    String script="redis.call('SET', KEYS[1], ARGV[1]);"
            +"return redis.call('GET', KEYS[1]);";
    List<String> keys= Arrays.asList("age");
    List<String> values= Arrays.asList("eighteen");
    Object result = jedis.eval(script, keys, values);
    System.out.println(result);
}

執(zhí)行上面的代碼，控制臺打印了get命令返回的結(jié)果：

eighteen

簡單的鋪墊完成后，我們來看一下lua腳本究竟能否實(shí)現(xiàn)回滾級別的原子性。對上面的代碼進(jìn)行改造，插入一條運(yùn)行錯(cuò)誤的命令：

public static void main(String[] args) {
    Jedis jedis = new Jedis("127.0.0.1", 6379);
    String script="redis.call('SET', KEYS[1], ARGV[1]);"
            +"redis.call('INCR', KEYS[1]);"
            +"return redis.call('GET', KEYS[1]);";
    List<String> keys= Arrays.asList("age");
    List<String> values= Arrays.asList("eighteen");
    Object result = jedis.eval(script, keys, values);
    System.out.println(result);
}

查看執(zhí)行結(jié)果：

再到客戶端執(zhí)行一下get命令：

127.0.0.1:6379> get age
"eighteen"

也就是說，雖然程序拋出了異常，但異常前的命令還是被正常的執(zhí)行了且沒有被回滾。再試試直接在redis客戶端中運(yùn)行這條指令：

127.0.0.1:6379> flushall
OK
127.0.0.1:6379> eval "redis.call('SET', KEYS[1], ARGV[1]);redis.call('INCR', KEYS[1]);return redis.call('GET', KEYS[1])" 1 age eight
(error) ERR Error running script (call to f_c2ea9d5c8f60735ecbedb47efd42c834554b9b3b): @user_script:1: ERR value is not an integer or out of range
127.0.0.1:6379> get age
"eight"

同樣，錯(cuò)誤之前的指令仍然沒有被回滾，那么我們之前經(jīng)常聽說的Lua腳本保證原子性操作究竟是怎么回事呢？

其實(shí)，在redis中是使用的同一個(gè)lua解釋器來執(zhí)行所有命令，也就保證了當(dāng)一段lua腳本在執(zhí)行時(shí)，不會有其他腳本或redis命令同時(shí)執(zhí)行，保證了操作不會被其他指令插入或打擾，實(shí)現(xiàn)的僅僅是這種程度上的原子操作。

但是遺憾的是，如果lua腳本運(yùn)行時(shí)出錯(cuò)并中途結(jié)束，之后的操作不會進(jìn)行，但是之前已經(jīng)發(fā)生的寫操作不會撤銷，所以即使使用了lua腳本，也不能實(shí)現(xiàn)類似數(shù)據(jù)庫回滾的原子性。

本文基于redis 5.0.3 進(jìn)行測試

官方文檔相關(guān)說明：https://redis.io/topics/transactions

有道無術(shù)，術(shù)可成；有術(shù)無道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號

好文章，我在看??