Redis 事務(wù)知識(shí)點(diǎn)相關(guān)總結(jié)

Redis中的事務(wù)介紹
    MySQL中的事務(wù)大家都不陌生，Redis中的事務(wù)和MySQL中的事務(wù)不同，今天看下Redis事務(wù)中的一些知識(shí)點(diǎn)吧。

01 事務(wù)簡(jiǎn)介

    Redis中的事務(wù)使用multi、exec來標(biāo)記，其中multi代表事務(wù)開始，exec代表事務(wù)結(jié)束，multi和exec之間的命令是原子順序執(zhí)行的。下面是一個(gè)例子：

127.0.0.1:7397> multi
OK
127.0.0.1:7397> set key_hello hello
QUEUED
127.0.0.1:7397> set key_world world
QUEUED
127.0.0.1:7397> exec
1) OK
2) OK

 需要注意的是，命令執(zhí)行的中間結(jié)果返回都是queued，也就是說放到了隊(duì)列里面，沒有真正執(zhí)行。在exec之前，如果使用get命令來查看當(dāng)前的key_hello或者key_world的值，是無法獲取到的。

02 命令錯(cuò)誤導(dǎo)致的事務(wù)提交失敗，所有命令都不執(zhí)行

  如果調(diào)用API的時(shí)候，拼寫錯(cuò)誤，則會(huì)造成整個(gè)事務(wù)無法執(zhí)行，例如下面的例子：

127.0.0.1:7397> multi
OK
127.0.0.1:7397> incr counter
QUEUED
127.0.0.1:7397> sett key_a aa
(error) ERR unknown command `sett`, with args beginning with: `key_a`, `aa`, 
127.0.0.1:7397> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:7397> get counter
"10"

 可以看到，因?yàn)閟et拼寫錯(cuò)誤，寫成了sett，整個(gè)事務(wù)內(nèi)部的所有動(dòng)作都失效。exec命令也報(bào)錯(cuò)。

03 運(yùn)行時(shí)錯(cuò)誤導(dǎo)致數(shù)據(jù)錯(cuò)誤

 如果語法正確，但是在運(yùn)行的時(shí)候出現(xiàn)了"運(yùn)行時(shí)"錯(cuò)誤，例如元素的類型和操作符不匹配，例如對(duì)字符型值進(jìn)行自增操作，如下：

127.0.0.1:7397> get key_a
"a"
127.0.0.1:7397> get key_b
"b"
127.0.0.1:7397> multi
OK
127.0.0.1:7397> incr key_a
QUEUED
127.0.0.1:7397> set key_b bbb
QUEUED
127.0.0.1:7397> exec
1) (error) ERR value is not an integer or out of range
2) OK
127.0.0.1:7397> get key_b
"bbb"

  對(duì)key_a進(jìn)行自增這類錯(cuò)誤，它的語法是正確的，但是由于key_a是字符型的，自增操作是不合適的，事務(wù)中還對(duì)key_b進(jìn)行了賦值操作，在執(zhí)行exec的時(shí)候，key_b的值是被修改的，從"b"變成了“bbb”。

04 丟棄事務(wù)

   直接看例子，在執(zhí)行的最后，使用discard關(guān)鍵字對(duì)事務(wù)進(jìn)行丟棄，那么事務(wù)執(zhí)行過程中產(chǎn)生的key是沒有值的。

127.0.0.1:7397> multi
OK
127.0.0.1:7397> set key_aa aa
QUEUED
127.0.0.1:7397> set key_bb bb
QUEUED
127.0.0.1:7397> set key_cc cc
QUEUED
127.0.0.1:7397> discard
OK
127.0.0.1:7397> get key_aa
(nil)
127.0.0.1:7397> get key_bb
(nil)
127.0.0.1:7397> get key_cc
(nil)

05 watch命令

  有些場(chǎng)景中，需要在事務(wù)之前，確保事務(wù)中的key沒有被其他客戶端修改過，才執(zhí)行事務(wù)，否則不執(zhí)行事務(wù)，redis提供了watch命令來解決這類問題。

正確場(chǎng)景：

127.0.0.1:7397> watch key_a
OK
127.0.0.1:7397> multi
OK
127.0.0.1:7397> set key_a aaa
QUEUED
127.0.0.1:7397> exec
1) OK
127.0.0.1:7397> get key_a
"aaa"

使用watch監(jiān)控key_a的值，在exec之前，key_a的值沒有被其他事務(wù)修改過，那么exec的結(jié)果是成功的。

錯(cuò)誤場(chǎng)景：

127.0.0.1:7397> watch key_a
OK
127.0.0.1:7397> get key_a
"aaa"
----------------------------------------
此時(shí)在另外一個(gè)session上執(zhí)行set key_a aaaaaa
----------------------------------------
127.0.0.1:7397> multi 
OK
127.0.0.1:7397> set key_a a
QUEUED
127.0.0.1:7397> exec
(nil)

在watch的過程中，其他session對(duì)key_a的值進(jìn)行了修改，那么會(huì)造成exec執(zhí)行失敗，返回nil

06 總結(jié)

1、Redis事務(wù)就是一次性、順序性、排他性的執(zhí)行一個(gè)隊(duì)列中的一系列命令，分為三個(gè)過程：開始事務(wù)、命令入隊(duì)、執(zhí)行事務(wù)。

2、Redis提供了簡(jiǎn)單的事務(wù)，使用multi、exec、discard這三個(gè)命令來控制

3、exec命令前，所有的原子操作都被放在隊(duì)列中緩存，并不會(huì)真正執(zhí)行

4、Redis事務(wù)不存在隔離級(jí)別的概念

5、事務(wù)中的單條命令是原子執(zhí)行的，但是事務(wù)本身不保證原子性，沒有回滾機(jī)制

以上就是Redis 事務(wù)相關(guān)總結(jié)的詳細(xì)內(nèi)容，更多關(guān)于Redis 事務(wù)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！