文章目錄

• 概述
• 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成功提交的事務的案例

時刻客戶端說明

T1	set key1 value1	初始化 key1
T2	watch key1	監控 key1 的健值對
T3	multi	開啟事務
T4	set key2 value2	設置 key2 的值
T5	exec	提交事務， Redis會在這個時間點檢測 key1 的值在 T2 時刻后，有沒有被其他命令修改泣，如果沒有 ， 則提交事務去執行

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>

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

---

使用watch回滾的事務的案例

時刻客戶端1客戶端2說明

T1	set key1 value1	—	客戶端 1 ：返回 OK
T2	watch key1	—	客戶端 1 ：監控 key1
T3	multi	—	客戶端 1： 開啟事務
T4	set key2 value2	—	客戶端1 ： 事務命令入列
T5	—	set key1 val1	客戶端 2：修改 key1的值
T6	exec	—	客戶端 1：執行事務，但是事務會先檢查在 T2 時刻被監控的 key1 是否被其他命令修改過。因為客戶揣 2 修改過，所以它會回滾事務，事實上如果客戶端執行的是 set key1 value1 命令，它也會認為 key1 被修改過，然后返回( nil) ，所以是不會產生 ABA 問題的

客戶端一

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 執行exec

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

總結

以上是生活随笔為你收集整理的Redis-11使用 watch 命令监控事务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。