wordpress購(gòu)買服務(wù)器百度seo搜索營(yíng)銷新視角
什么是Redis事務(wù)
Redis 事務(wù)的本質(zhì)是一組命令的集合。事務(wù)支持一次執(zhí)行多個(gè)命令,一個(gè)事務(wù)中所有命令都會(huì)被序列化。在事務(wù)執(zhí)行過程,會(huì)按照順序串行化執(zhí)行隊(duì)列中的命令,其他客戶端提交的命令請(qǐng)求不會(huì)插入到事務(wù)執(zhí)行命令序列中。
總結(jié)說:redis事務(wù)就是一次性、順序性、排他性的執(zhí)行一個(gè)隊(duì)列中的一系列命令。
Redis事務(wù)相關(guān)命令和使用
MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事務(wù)相關(guān)的命令。
- MULTI :開啟事務(wù),redis會(huì)將后續(xù)的命令逐個(gè)放入隊(duì)列中,然后使用EXEC命令來原子化執(zhí)行這個(gè)命令系列。
- EXEC:執(zhí)行事務(wù)中的所有操作命令。
- DISCARD:取消事務(wù),放棄執(zhí)行事務(wù)塊中的所有命令。
- WATCH:監(jiān)視一個(gè)或多個(gè)key,如果事務(wù)在執(zhí)行前,這個(gè)key(或多個(gè)key)被其他命令修改,則事務(wù)被中斷,不會(huì)執(zhí)行事務(wù)中的任何命令。
- UNWATCH:取消WATCH對(duì)所有key的監(jiān)視。
標(biāo)準(zhǔn)的事務(wù)執(zhí)行
給k1、k2分別賦值,在事務(wù)中修改k1、k2,執(zhí)行事務(wù)后,查看k1、k2值都被修改。
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 11
QUEUED
127.0.0.1:6379> set k2 22
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
127.0.0.1:6379> get k1
"11"
127.0.0.1:6379> get k2
"22"
127.0.0.1:6379>
事務(wù)取消
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 33
QUEUED
127.0.0.1:6379> set k2 34
QUEUED
127.0.0.1:6379> DISCARD
OK
事務(wù)出現(xiàn)錯(cuò)誤的處理
- 語法錯(cuò)誤(編譯器錯(cuò)誤)
在開啟事務(wù)后,修改k1值為11,k2值為22,但k2語法錯(cuò)誤,最終導(dǎo)致事務(wù)提交失敗,k1、k2保留原值。
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 11
QUEUED
127.0.0.1:6379> sets k2 22
(error) ERR unknown command `sets`, with args beginning with: `k2`, `22`,
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379>
- Redis類型錯(cuò)誤(運(yùn)行時(shí)錯(cuò)誤)
在開啟事務(wù)后,修改k1值為11,k2值為22,但將k2的類型作為L(zhǎng)ist,在運(yùn)行時(shí)檢測(cè)類型錯(cuò)誤,最終導(dǎo)致事務(wù)提交失敗,此時(shí)事務(wù)并沒有回滾,而是跳過錯(cuò)誤命令繼續(xù)執(zhí)行, 結(jié)果k1值改變、k2保留原值
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k1 v2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 11
QUEUED
127.0.0.1:6379> lpush k2 22
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> get k1
"11"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379>
CAS操作實(shí)現(xiàn)樂觀鎖
WATCH 命令可以為 Redis 事務(wù)提供 check-and-set (CAS)行為。
被 WATCH 的鍵會(huì)被監(jiān)視,并會(huì)發(fā)覺這些鍵是否被改動(dòng)過了。 如果有至少一個(gè)被監(jiān)視的鍵在 EXEC 執(zhí)行之前被修改了, 那么整個(gè)事務(wù)都會(huì)被取消, EXEC 返回nil-reply來表示事務(wù)已經(jīng)失敗。
舉個(gè)例子, 假設(shè)我們需要原子性地為某個(gè)值進(jìn)行增 1 操作(假設(shè) INCR 不存在)。
val = GET mykey
val = val + 1
SET mykey $val
上面的這個(gè)實(shí)現(xiàn)在只有一個(gè)客戶端的時(shí)候可以執(zhí)行得很好。 但是, 當(dāng)多個(gè)客戶端同時(shí)對(duì)同一個(gè)鍵進(jìn)行這樣的操作時(shí), 就會(huì)產(chǎn)生競(jìng)爭(zhēng)條件。舉個(gè)例子, 如果客戶端 A 和 B 都讀取了鍵原來的值, 比如 10 , 那么兩個(gè)客戶端都會(huì)將鍵的值設(shè)為 11 , 但正確的結(jié)果應(yīng)該是 12 才對(duì)。
有了 WATCH ,我們就可以輕松地解決這類問題了:
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
使用上面的代碼, 如果在 WATCH 執(zhí)行之后, EXEC 執(zhí)行之前, 有其他客戶端修改了 mykey 的值, 那么當(dāng)前客戶端的事務(wù)就會(huì)失敗。 程序需要做的, 就是不斷重試這個(gè)操作, 直到?jīng)]有發(fā)生碰撞為止。
這種形式的鎖被稱作樂觀鎖, 它是一種非常強(qiáng)大的鎖機(jī)制。 并且因?yàn)榇蠖鄶?shù)情況下, 不同的客戶端會(huì)訪問不同的鍵, 碰撞的情況一般都很少, 所以通常并不需要進(jìn)行重試。
- watch是如何監(jiān)視實(shí)現(xiàn)的呢?
Redis使用WATCH命令來決定事務(wù)是繼續(xù)執(zhí)行還是回滾,那就需要在MULTI之前使用WATCH來監(jiān)控某些鍵值對(duì),然后使用MULTI命令來開啟事務(wù),執(zhí)行對(duì)數(shù)據(jù)結(jié)構(gòu)操作的各種命令,此時(shí)這些命令入隊(duì)列。
當(dāng)使用EXEC執(zhí)行事務(wù)時(shí),首先會(huì)比對(duì)WATCH所監(jiān)控的鍵值對(duì),如果沒發(fā)生改變,它會(huì)執(zhí)行事務(wù)隊(duì)列中的命令,提交事務(wù);如果發(fā)生變化,將不會(huì)執(zhí)行事務(wù)中的任何命令,同時(shí)事務(wù)回滾。當(dāng)然無論是否回滾,Redis都會(huì)取消執(zhí)行事務(wù)前的WATCH命令。
- watch 命令實(shí)現(xiàn)監(jiān)視
在事務(wù)開始前用WATCH監(jiān)控k1,之后修改k1為11,說明事務(wù)開始前k1值被改變,MULTI開始事務(wù),修改k1值為12,k2為22,執(zhí)行EXEC,發(fā)回nil,說明事務(wù)回滾;查看下k1、k2的值都沒有被事務(wù)中的命令所改變。
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> WATCH k1
OK
127.0.0.1:6379> set k1 11
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 12
QUEUED
127.0.0.1:6379> set k2 22
QUEUED
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> get k1
"11"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379>
Redis事務(wù)執(zhí)行步驟
通過上文命令執(zhí)行,很顯然Redis事務(wù)執(zhí)行是三個(gè)階段:
-
開啟:以MULTI開始一個(gè)事務(wù)
-
入隊(duì):將多個(gè)命令入隊(duì)到事務(wù)中,接到這些命令并不會(huì)立即執(zhí)行,而是放到等待執(zhí)行的事務(wù)隊(duì)列里面
-
執(zhí)行:由EXEC命令觸發(fā)事務(wù)
當(dāng)一個(gè)客戶端切換到事務(wù)狀態(tài)之后, 服務(wù)器會(huì)根據(jù)這個(gè)客戶端發(fā)來的不同命令執(zhí)行不同的操作:
- 如果客戶端發(fā)送的命令為 EXEC 、 DISCARD 、 WATCH 、 MULTI 四個(gè)命令的其中一個(gè), 那么服務(wù)器立即執(zhí)行這個(gè)命令。
- 與此相反, 如果客戶端發(fā)送的命令是 EXEC 、 DISCARD 、 WATCH 、 MULTI 四個(gè)命令以外的其他命令, 那么服務(wù)器并不立即執(zhí)行這個(gè)命令, 而是將這個(gè)命令放入一個(gè)事務(wù)隊(duì)列里面, 然后向客戶端返回 QUEUED 回復(fù)。
更深入的理解
我們?cè)偻ㄟ^幾個(gè)問題來深入理解Redis事務(wù)。
為什么 Redis 不支持回滾?
如果你有使用關(guān)系式數(shù)據(jù)庫(kù)的經(jīng)驗(yàn), 那么 “Redis 在事務(wù)失敗時(shí)不進(jìn)行回滾,而是繼續(xù)執(zhí)行余下的命令”這種做法可能會(huì)讓你覺得有點(diǎn)奇怪。
以下是這種做法的優(yōu)點(diǎn):
- Redis 命令只會(huì)因?yàn)殄e(cuò)誤的語法而失敗(并且這些問題不能在入隊(duì)時(shí)發(fā)現(xiàn)),或是命令用在了錯(cuò)誤類型的鍵上面:這也就是說,從實(shí)用性的角度來說,失敗的命令是由編程錯(cuò)誤造成的,而這些錯(cuò)誤應(yīng)該在開發(fā)的過程中被發(fā)現(xiàn),而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。
- 因?yàn)椴恍枰獙?duì)回滾進(jìn)行支持,所以 Redis 的內(nèi)部可以保持簡(jiǎn)單且快速。
有種觀點(diǎn)認(rèn)為 Redis 處理事務(wù)的做法會(huì)產(chǎn)生 bug , 然而需要注意的是, 在通常情況下, 回滾并不能解決編程錯(cuò)誤帶來的問題。 舉個(gè)例子, 如果你本來想通過 INCR 命令將鍵的值加上 1 , 卻不小心加上了 2 , 又或者對(duì)錯(cuò)誤類型的鍵執(zhí)行了 INCR , 回滾是沒有辦法處理這些情況的。
如何理解Redis與事務(wù)的ACID?
一般來說,事務(wù)有四個(gè)性質(zhì)稱為ACID,分別是原子性,一致性,隔離性和持久性。這是基礎(chǔ),但是很多文章對(duì)Redis 是否支持ACID有一些異議,我覺的有必要梳理下:
- 原子性atomicity
首先通過上文知道 運(yùn)行期的錯(cuò)誤是不會(huì)回滾的,很多文章由此說Redis事務(wù)違背原子性的;而官方文檔認(rèn)為是遵從原子性的。
Redis官方文檔給的理解是,Redis的事務(wù)是原子性的:所有的命令,要么全部執(zhí)行,要么全部不執(zhí)行。而不是完全成功。
- 一致性consistency
redis事務(wù)可以保證命令失敗的情況下得以回滾,數(shù)據(jù)能恢復(fù)到?jīng)]有執(zhí)行之前的樣子,是保證一致性的,除非redis進(jìn)程意外終結(jié)。
- 一致性consistency
redis事務(wù)可以保證命令失敗的情況下得以回滾,數(shù)據(jù)能恢復(fù)到?jīng)]有執(zhí)行之前的樣子,是保證一致性的,除非redis進(jìn)程意外終結(jié)。但是,Redis不像其它結(jié)構(gòu)化數(shù)據(jù)庫(kù)有隔離級(jí)別這種設(shè)計(jì)。
- 持久性Durability
redis事務(wù)是不保證持久性的,這是因?yàn)閞edis持久化策略中不管是RDB還是AOF都是異步執(zhí)行的,不保證持久性是出于對(duì)性能的考慮。
?
?
?
?
?
?