Redis事務如何實現(xiàn)

今天小編給大家分享一下Redis事務如何實現(xiàn)的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

ACID屬性說明

原子性(Atomicity)

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

一致性(Consistency)

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

隔離性(Isolation)

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

持久性(Durability)

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

Redis如何實現(xiàn)事務

實現(xiàn)原理

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

• 客戶端使用MULTI命令顯式地開啟一個事務。

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

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

事務相關命令

• MULTI ：開啟事務

• EXEC：提交事務，執(zhí)行命令隊列中所有的操作命令。

• DISCARD:放棄一個事務，清空命令隊列，但是無法支持事務的回滾。

• WATCH:檢測一個或多個鍵的值在事務執(zhí)行的期間是否發(fā)生變化，如果發(fā)生變化，那么當前事務放棄執(zhí)行。

Redis的事務如何支持ACID

Redis事務的支持原子性嗎？

• 情況一：執(zhí)行事務在入隊時就報錯，那么Redis會放棄事務執(zhí)行，從而保證事務原子性。

• 情況二：命令在入隊時沒報錯，但是實際執(zhí)行時卻報錯，無法保證事務原子性。

情況一示例說明

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ā)生語法錯誤(使用了不存在的命令)，那么命令入隊時,Redis就會報錯并且記錄錯誤，等到執(zhí)行Exec命令之后，Redi會拒絕所有提交的命令，事務執(zhí)行失敗。這種情況Reids的事務是可以支持原子性。

情況二示例說明

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，當執(zhí)行incr命令時報報錯，因為incr只能新增integer的類型值，但是這種情況下我們發(fā)現(xiàn)Redis的事務沒有進行回滾，后面的命令能夠執(zhí)行成功，所以這種情況下時無法保證事務的原子性。

Redis事務的支持一致性嗎？

情況一：命令入隊時就報錯

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

情況二：命令入隊時沒報錯，實際執(zhí)行時報錯

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

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

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

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

Redis事務的支持隔離性嗎？

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

示例說明

客戶端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檢測balance，在開啟事務后，在客戶端2執(zhí)行更改balance的值操作，模擬其他客戶端在事務執(zhí)行期間更改watch監(jiān)控的數據，然后再執(zhí)行客戶端1的EXEC命令，發(fā)現(xiàn)事務未成功執(zhí)行。

Redis事務的支持持久性嗎？

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

以上就是“Redis事務如何實現(xiàn)”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業(yè)資訊頻道。