您好,登錄后才能下訂單哦!
今天小編給大家分享一下Redis事務如何實現的相關知識點,內容詳細,邏輯清晰,相信大部分人都還太了解這方面的知識,所以分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后有所收獲,下面我們一起來了解一下吧。
事務中的全部操作在數據庫中是不可分割的,要么全部完成,要么全部不執行。
事務的執行使數據從一個狀態轉換為另一個狀態,在事務開始之前和事務結束之后,數據庫的完整性約束沒有被破壞。
事務的隔離性要求每個讀寫事務的對象對其他事務的操作對象相互分離,即該事務提交前對其他事務都不可見。
數據庫執行事務后,數據的修改要被持久化保存下來。當數據庫重啟后,數據的值需要是被修改后的值。
Redis事務的執行包含了三個步驟,具體如下:
客戶端使用MULTI命令顯式地開啟一個事務。
客戶端把事務中本身要執行的具體操作(例如增刪改數據)發送給服務器端。這些操作就是Redis 本身提供的數據讀寫命令,雖然這些命令被客戶端發送到了服務器端,但是Redis實例只是把這些命令暫存到一個命令隊列中,并不會立即執行。
Redis執行EXEC命令執行事務提交,服務器端收到EXEC命令后,才會實際執行命令隊列中的所有命令。
MULTI :開啟事務
EXEC:提交事務,執行命令隊列中所有的操作命令。
DISCARD:放棄一個事務,清空命令隊列,但是無法支持事務的回滾。
WATCH:檢測一個或多個鍵的值在事務執行的期間是否發生變化,如果發生變化,那么當前事務放棄執行。
情況一:執行事務在入隊時就報錯,那么Redis會放棄事務執行,從而保證事務原子性。
情況二:命令在入隊時沒報錯,但是實際執行時卻報錯,無法保證事務原子性。
情況一示例說明
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)
說明:在執行exec命令之前,如果發生語法錯誤(使用了不存在的命令),那么命令入隊時,Redis就會報錯并且記錄錯誤,等到執行Exec命令之后,Redi會拒絕所有提交的命令,事務執行失敗。這種情況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,當執行incr命令時報報錯,因為incr只能新增integer的類型值,但是這種情況下我們發現Redis的事務沒有進行回滾,后面的命令能夠執行成功,所以這種情況下時無法保證事務的原子性。
針對第一種情況,事務本身就會被放棄執行,所以可以保證事務的一致性。
針對第二種情況,有錯誤的命令不會被執行,正確的命令可以正常執行,也不會改變數據庫的一致性。
如果Redis持久化設置為RDB,那么生成RDB快照不會在事務執行時執行,所以事務命令操作的結果不會被保存到RDB快照中,使用RDB快照進行恢復時,數據庫里的數據也是一致的。
如果Reids持久化設置為AOF,而事務操作還沒有被記錄到AOF日志時,實例就發生了故障,那么,使用AOF日志恢復的數據庫數據是一致的。如果只有部分操作被記錄到了AOF日志,我們可以使用 redis-check-aof 清除事務中已經完成的操作,數據庫恢復后也是一致的。
Redis實現事務的隔離性,需要通過watch命令來支持事務隔離性。Watch的原理是,在事務執行前,監控一個或者多個鍵的變化時,當事務調用EXEC命令執行時,WATCH機制會先檢查監控的鍵是否被其它客戶端修改了。如果修改了監聽的值,就放棄事務執行,避免事務的隔離性被破壞。
示例說明
客戶端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執行更改balance的值操作,模擬其他客戶端在事務執行期間更改watch監控的數據,然后再執行客戶端1的EXEC命令,發現事務未成功執行。
Redis的事務無法支持持久性,如果Redis使用了RDB模式,一個事務執行后,當下一次的RDB快照還未執行前,Redis發生了實例宕機,那么這種情況下,事務修改的數據是無法保證持久化的,如果Redis采用AOF模式,如論持久化配置為no、everysec和always都可能會存在數據丟失,所以,不管 Redis采用那種持久化模式,事務的持久性都無法支持。
以上就是“Redis事務如何實現”這篇文章的所有內容,感謝各位的閱讀!相信大家閱讀完這篇文章都有很大的收獲,小編每天都會為大家更新不同的知識,如果還想學習更多的知識,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。