Redis-11使用 watch 命令監控事務

文章目錄

概述

Redis watch流程

ABA問題

使用watch成功提交的事務的案例

使用watch回滾的事務的案例

概述

在 Redis 中使用 watch 命令可以決定事務是執行還是回滾。

一般而言，可以在 multi 命令之前使用 watch 命令監控某些鍵值對，然后使用 multi 命令開啟事務，執行各類對數據結構進行操作的命令，這個時候這些命令就會進入隊列。

當 Redis 使用 exec 命令執行事務的時候，它首先會去比對被 watch 命令所監控的鍵值對，

如果沒有發生變化，那么它會執行事務隊列中的命令，提交事務；

如果發生變化，那么它不會執行任何事務中的命令，而去事務回滾。

無論事務是否回滾 ， Redis 都會去取消執行事務前的 watch 命令

Redis watch流程

流程如下：

Redis 參考了多線程中使用的 CAS （比較與交換， Compare And Swap ） 去執行的。在

數據高并發環境的操作中，我們把這樣的一個機制稱為樂觀鎖.

ABA問題

先簡要論述其操作的過程:

當一條線程去執行某些業務邏輯，但是這些業務務邏輯操作的數據可能被其他線程共享了，這樣會引發多線程中數據不一致的情況。為了克服這個問題，首先，在線程開始時讀取這些多線程共享的數據，并將其保存到當前進程的副本中，我們稱為舊值（ old value), watch 命令就是這樣的一個功能 。

然后，開啟線程業務邏輯，由 multi 命令提供這一功能。在執行更新前，比較當前線程副本保存的舊值和當前線程共享的值是否一致，如果不一致，那么該數據己經被其他線程操作過，此次更新失敗。為了保持一致，線程就不去更新任何值，而將事務回滾：否則就認為它沒有被其他線程操作過，執行對應的業務邏輯， exec 命令就是執行“類似”這樣的一個功能 。

注意，“類似”這個字眼，因為不完全是，原因是 CAS 原理會產生 ABA 問題。所謂ABA 問題來自于 CAS 原理的一個設計缺陷，它可能引發 ABA 問題

在處理復雜運算的時候，被線程 2 修改的 X 的值有可能導致線程1的運算出錯，而最后線程 2 將 X 的值修改為原來的舊值 A，那么到了線程 1運算結束的時間順序 T6，它將j檢測 X 的值是否發生變化，就會拿舊值 A 和 當前的 X 的值 A 比對 ， 結果是一致的， 于是提交事務，然后在復雜計算的過程中 X 被線程 2 修改過了，這會導致線程1的運算出錯。

在這個過程中，對于線程 2 而言 ， X 的值的變化為 A->B->A，所以 CAS 原理的這個設計缺陷被形象地稱為“ABA 問題”。

僅僅記錄一個舊值去比較是不足夠的，還要通過其他方法避免 ABA 問題。常見的方法

如 Hibernate 對緩存的持久對象（ PO ）加入字段段 version 值，當每次操作一次該 PO，則version=version+ 1 ， 這樣采用 CAS 原理探測 version 宇段 ， 就能在多線程的環境中，排除ABA 問題，從而保證數據的一致性。

Redis 在執行事務的過程中 ， 并不會阻塞其他連接的并發，而只是通過 比較 watch 監控的鍵值對去保證數據的一致性 ， 所 以 Redis 多個事務完全可 以在非阻塞的多線程環境中井發執行，而且 Redis 的機制是不會產生 ABA 問題的， 這樣就有利于在保證數據一致的基礎上 ， 提高高并發系統的數據讀／寫性能。

使用watch成功提交的事務的案例

127.0.0.1:6379> FLUSHDB OK 127.0.0.1:6379> SET key1 value1 OK 127.0.0.1:6379> WATCH key1 OK 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET key2 value2 QUEUED 127.0.0.1:6379> EXEC 1) OK 127.0.0.1:6379>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

這里我們使用了 watch 命令設置了 一個 key1 的監控 ， 然后開啟事務設置 key2 ， 直至exec 命令去執行事務. 如果在當前會話中修改key1的值，也是可以成功的。

使用watch回滾的事務的案例

客戶端一

127.0.0.1:6379> FLUSHDB OK 127.0.0.1:6379> 127.0.0.1:6379> SET key1 value1 OK 127.0.0.1:6379> WATCH key1 OK 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> set key2 value2 QUEUED # 在這一步暫停下，打開第二個客戶端去修改key1的值，然后再exec 127.0.0.1:6379> exec (nil) 127.0.0.1:6379>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

客戶端二：

然后回到客戶端1 執行exec

注意 T2 和 T6 時刻命令的說明，數據已經被回滾了，并沒有執行事務。

Redis 任務調度

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。