前言

說到事務(wù)，大家會(huì)立刻想到Mysql的事務(wù)，所謂的事務(wù)就是對(duì)數(shù)據(jù)進(jìn)行一系列的操作，要么都執(zhí)行成功，要么都執(zhí)行失敗，事務(wù)提供了原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability),簡(jiǎn)稱ACID。這些屬性既包括了對(duì)事務(wù)執(zhí)行結(jié)果的要求，也有對(duì)數(shù)據(jù)庫在事務(wù)執(zhí)行前后的數(shù)據(jù)狀態(tài)變化的要求。那么Redis的事務(wù)能支持ACID嗎？

ACID屬性說明

原子性(Atomicity)

事務(wù)中的全部操作在數(shù)據(jù)庫中是不可分割的，要么全部完成，要么全部不執(zhí)行。

一致性(Consistency)

事務(wù)的執(zhí)行使數(shù)據(jù)從一個(gè)狀態(tài)轉(zhuǎn)換為另一個(gè)狀態(tài),在事務(wù)開始之前和事務(wù)結(jié)束之后，數(shù)據(jù)庫的完整性約束沒有被破壞。

隔離性(Isolation)

事務(wù)的隔離性要求每個(gè)讀寫事務(wù)的對(duì)象對(duì)其他事務(wù)的操作對(duì)象相互分離，即該事務(wù)提交前對(duì)其他事務(wù)都不可見。

持久性(Durability)

數(shù)據(jù)庫執(zhí)行事務(wù)后，數(shù)據(jù)的修改要被持久化保存下來。當(dāng)數(shù)據(jù)庫重啟后，數(shù)據(jù)的值需要是被修改后的值。

Redis如何實(shí)現(xiàn)事務(wù)

實(shí)現(xiàn)原理

Redis事務(wù)的執(zhí)行包含了三個(gè)步驟，具體如下：

• 客戶端使用MULTI命令顯式地開啟一個(gè)事務(wù)。

• 客戶端把事務(wù)中本身要執(zhí)行的具體操作（例如增刪改數(shù)據(jù)）發(fā)送給服務(wù)器端。這些操作就是Redis 本身提供的數(shù)據(jù)讀寫命令，雖然這些命令被客戶端發(fā)送到了服務(wù)器端，但是Redis實(shí)例只是把這些命令暫存到一個(gè)命令隊(duì)列中，并不會(huì)立即執(zhí)行。

• Redis執(zhí)行EXEC命令執(zhí)行事務(wù)提交，服務(wù)器端收到EXEC命令后，才會(huì)實(shí)際執(zhí)行命令隊(duì)列中的所有命令。

事務(wù)相關(guān)命令

• MULTI ：開啟事務(wù)
• EXEC：提交事務(wù)，執(zhí)行命令隊(duì)列中所有的操作命令。
• DISCARD:放棄一個(gè)事務(wù)，清空命令隊(duì)列，但是無法支持事務(wù)的回滾。
• WATCH:檢測(cè)一個(gè)或多個(gè)鍵的值在事務(wù)執(zhí)行的期間是否發(fā)生變化，如果發(fā)生變化，那么當(dāng)前事務(wù)放棄執(zhí)行。

Redis的事務(wù)如何支持ACID

Redis事務(wù)的支持原子性嗎？

• 情況一：執(zhí)行事務(wù)在入隊(duì)時(shí)就報(bào)錯(cuò)，那么Redis會(huì)放棄事務(wù)執(zhí)行，從而保證事務(wù)原子性。
• 情況二：命令在入隊(duì)時(shí)沒報(bào)錯(cuò)，但是實(shí)際執(zhí)行時(shí)卻報(bào)錯(cuò)，無法保證事務(wù)原子性。

情況一示例說明

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set t1 v1
QUEUED
127.0.0.1:6379> set t2 v2
QUEUED
127.0.0.1:6379> setget t3
(error) ERR unknown command 'setget'
127.0.0.1:6379> set t4 v4
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get t4
(nil)

說明：在執(zhí)行exec命令之前，如果發(fā)生語法錯(cuò)誤(使用了不存在的命令)，那么命令入隊(duì)時(shí),Redis就會(huì)報(bào)錯(cuò)并且記錄錯(cuò)誤，等到執(zhí)行Exec命令之后，Redi會(huì)拒絕所有提交的命令，事務(wù)執(zhí)行失敗。這種情況Reids的事務(wù)是可以支持原子性。

情況二示例說明

127.0.0.1:6379> multi 
OK
127.0.0.1:6379> incr s2
QUEUED
127.0.0.1:6379> set a1 v1
QUEUED
127.0.0.1:6379> set a2 v2
QUEUED
127.0.0.1:6379> exec
1) (error) ERR value is not an integer or out of range
2) OK
3) OK
127.0.0.1:6379> get a2
"v2"

說明: s2的值為v2，當(dāng)執(zhí)行incr命令時(shí)報(bào)報(bào)錯(cuò)，因?yàn)閕ncr只能新增integer的類型值，但是這種情況下我們發(fā)現(xiàn)Redis的事務(wù)沒有進(jìn)行回滾，后面的命令能夠執(zhí)行成功，所以這種情況下時(shí)無法保證事務(wù)的原子性。

Redis事務(wù)的支持一致性嗎？

情況一：命令入隊(duì)時(shí)就報(bào)錯(cuò)

針對(duì)第一種情況，事務(wù)本身就會(huì)被放棄執(zhí)行，所以可以保證事務(wù)的一致性。

情況二：命令入隊(duì)時(shí)沒報(bào)錯(cuò)，實(shí)際執(zhí)行時(shí)報(bào)錯(cuò)

針對(duì)第二種情況，有錯(cuò)誤的命令不會(huì)被執(zhí)行，正確的命令可以正常執(zhí)行，也不會(huì)改變數(shù)據(jù)庫的一致性。

情況三：Exec執(zhí)行命令Redis實(shí)例發(fā)生故障

• 如果Redis持久化設(shè)置為RDB，那么生成RDB快照不會(huì)在事務(wù)執(zhí)行時(shí)執(zhí)行，所以事務(wù)命令操作的結(jié)果不會(huì)被保存到RDB快照中，使用RDB快照進(jìn)行恢復(fù)時(shí)，數(shù)據(jù)庫里的數(shù)據(jù)也是一致的。

• 如果Reids持久化設(shè)置為AOF，而事務(wù)操作還沒有被記錄到AOF日志時(shí)，實(shí)例就發(fā)生了故障，那么，使用AOF日志恢復(fù)的數(shù)據(jù)庫數(shù)據(jù)是一致的。如果只有部分操作被記錄到了AOF日志，我們可以使用 redis-check-aof 清除事務(wù)中已經(jīng)完成的操作，數(shù)據(jù)庫恢復(fù)后也是一致的。

Redis事務(wù)的支持隔離性嗎？

Redis實(shí)現(xiàn)事務(wù)的隔離性，需要通過watch命令來支持事務(wù)隔離性。Watch的原理是，在事務(wù)執(zhí)行前，監(jiān)控一個(gè)或者多個(gè)鍵的變化時(shí)，當(dāng)事務(wù)調(diào)用EXEC命令執(zhí)行時(shí)，WATCH機(jī)制會(huì)先檢查監(jiān)控的鍵是否被其它客戶端修改了。如果修改了監(jiān)聽的值，就放棄事務(wù)執(zhí)行，避免事務(wù)的隔離性被破壞。

示例說明

客戶端1：

127.0.0.1:6379> get blance
"100"
127.0.0.1:6379> watch blance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby blance 10
QUEUED
127.0.0.1:6379> incrby blance 10
QUEUED
127.0.0.1:6379> exec
(nil)

客戶端2：

127.0.0.1:6379> get blance
"100"
127.0.0.1:6379> set blance 90
OK
127.0.0.1:6379> get blance
"90"

說明：客戶端1使用watch檢測(cè)balance，在開啟事務(wù)后，在客戶端2執(zhí)行更改balance的值操作，模擬其他客戶端在事務(wù)執(zhí)行期間更改watch監(jiān)控的數(shù)據(jù)，然后再執(zhí)行客戶端1的EXEC命令，發(fā)現(xiàn)事務(wù)未成功執(zhí)行。

Redis事務(wù)的支持持久性嗎？

Redis的事務(wù)無法支持持久性，如果Redis使用了RDB模式，一個(gè)事務(wù)執(zhí)行后，當(dāng)下一次的RDB快照還未執(zhí)行前，Redis發(fā)生了實(shí)例宕機(jī)，那么這種情況下，事務(wù)修改的數(shù)據(jù)是無法保證持久化的，如果Redis采用AOF模式，如論持久化配置為no、everysec和always都可能會(huì)存在數(shù)據(jù)丟失，所以，不管 Redis采用那種持久化模式，事務(wù)的持久性都無法支持。

總結(jié)

本文對(duì)Redis的事務(wù)進(jìn)行詳細(xì)的講解，Redis對(duì)于事務(wù)的支持還是有限制的，所以大家在使用的過程中需要注意。

到此這篇關(guān)于你了解Redis事務(wù)嗎的文章就介紹到這了,更多相關(guān)Redis 事務(wù)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論