Redis教程(八)：事務(wù)詳解
一、概述：
和眾多其它數(shù)據(jù)庫一樣，Redis作為NoSQL數(shù)據(jù)庫也同樣提供了事務(wù)機制。在Redis中，MULTI/EXEC/DISCARD/WATCH這四個命令是我們實現(xiàn)事務(wù)的基石。相信對有關(guān)系型數(shù)據(jù)庫開發(fā)經(jīng)驗的開發(fā)者而言這一概念并不陌生，即便如此，我們還是會簡要的列出Redis中事務(wù)的實現(xiàn)特征：
1). 在事務(wù)中的所有命令都將會被串行化的順序執(zhí)行，事務(wù)執(zhí)行期間，Redis不會再為其它客戶端的請求提供任何服務(wù)，從而保證了事物中的所有命令被原子的執(zhí)行。
2). 和關(guān)系型數(shù)據(jù)庫中的事務(wù)相比，在Redis事務(wù)中如果有某一條命令執(zhí)行失敗，其后的命令仍然會被繼續(xù)執(zhí)行。
3). 我們可以通過MULTI命令開啟一個事務(wù)，有關(guān)系型數(shù)據(jù)庫開發(fā)經(jīng)驗的人可以將其理解為"BEGIN TRANSACTION"語句。在該語句之后執(zhí)行的命令都將被視為事務(wù)之內(nèi)的操作，最后我們可以通過執(zhí)行EXEC/DISCARD命令來提交/回滾該事務(wù)內(nèi)的所有操作。這兩個Redis命令可被視為等同于關(guān)系型數(shù)據(jù)庫中的COMMIT/ROLLBACK語句。
4). 在事務(wù)開啟之前，如果客戶端與服務(wù)器之間出現(xiàn)通訊故障并導(dǎo)致網(wǎng)絡(luò)斷開，其后所有待執(zhí)行的語句都將不會被服務(wù)器執(zhí)行。然而如果網(wǎng)絡(luò)中斷事件是發(fā)生在客戶端執(zhí)行EXEC命令之后，那么該事務(wù)中的所有命令都會被服務(wù)器執(zhí)行。
5). 當(dāng)使用Append-Only模式時，Redis會通過調(diào)用系統(tǒng)函數(shù)write將該事務(wù)內(nèi)的所有寫操作在本次調(diào)用中全部寫入磁盤。然而如果在寫入的過程中出現(xiàn)系統(tǒng)崩潰，如電源故障導(dǎo)致的宕機，那么此時也許只有部分數(shù)據(jù)被寫入到磁盤，而另外一部分數(shù)據(jù)卻已經(jīng)丟失。Redis服務(wù)器會在重新啟動時執(zhí)行一系列必要的一致性檢測，一旦發(fā)現(xiàn)類似問題，就會立即退出并給出相應(yīng)的錯誤提示。此時，我們就要充分利用Redis工具包中提供的redis-check-aof工具，該工具可以幫助我們定位到數(shù)據(jù)不一致的錯誤，并將已經(jīng)寫入的部分數(shù)據(jù)進行回滾。修復(fù)之后我們就可以再次重新啟動Redis服務(wù)器了。
二、相關(guān)命令列表：
| 命令原型 | 時間復(fù)雜度 | 命令描述 | 返回值 |
| MULTI | 用于標(biāo)記事務(wù)的開始，其后執(zhí)行的命令都將被存入命令隊列，直到執(zhí)行EXEC時，這些命令才會被原子的執(zhí)行。 | 始終返回OK | |
| EXEC | 執(zhí)行在一個事務(wù)內(nèi)命令隊列中的所有命令，同時將當(dāng)前連接的狀態(tài)恢復(fù)為正常狀態(tài)，即非事務(wù)狀態(tài)。如果在事務(wù)中執(zhí)行了WATCH命令，那么只有當(dāng)WATCH所監(jiān)控的Keys沒有被修改的前提下，EXEC命令才能執(zhí)行事務(wù)隊列中的所有命令，否則EXEC將放棄當(dāng)前事務(wù)中的所有命令。 | 原子性的返回事務(wù)中各條命令的返回結(jié)果。如果在事務(wù)中使用了WATCH，一旦事務(wù)被放棄，EXEC將返回NULL-multi-bulk回復(fù)。 | |
| DISCARD | 回滾事務(wù)隊列中的所有命令，同時再將當(dāng)前連接的狀態(tài)恢復(fù)為正常狀態(tài)，即非事務(wù)狀態(tài)。如果WATCH命令被使用，該命令將UNWATCH所有的Keys。 | 始終返回OK。 | |
| WATCHkey [key ...] | O(1) | 在MULTI命令執(zhí)行之前，可以指定待監(jiān)控的Keys，然而在執(zhí)行EXEC之前，如果被監(jiān)控的Keys發(fā)生修改，EXEC將放棄執(zhí)行該事務(wù)隊列中的所有命令。 | 始終返回OK。 |
| UNWATCH | O(1) | 取消當(dāng)前事務(wù)中指定監(jiān)控的Keys，如果執(zhí)行了EXEC或DISCARD命令，則無需再手工執(zhí)行該命令了，因為在此之后，事務(wù)中所有被監(jiān)控的Keys都將自動取消。 | 始終返回OK。 |
三、命令示例：
1. 事務(wù)被正常執(zhí)行：
#在Shell命令行下執(zhí)行Redis的客戶端工具。
/> redis-cli
#在當(dāng)前連接上啟動一個新的事務(wù)。
redis 127.0.0.1:6379> multi
OK
#執(zhí)行事務(wù)中的第一條命令，從該命令的返回結(jié)果可以看出，該命令并沒有立即執(zhí)行，而是存于事務(wù)的命令隊列。
redis 127.0.0.1:6379> incr t1
QUEUED
#又執(zhí)行一個新的命令，從結(jié)果可以看出，該命令也被存于事務(wù)的命令隊列。
redis 127.0.0.1:6379> incr t2
QUEUED
#執(zhí)行事務(wù)命令隊列中的所有命令，從結(jié)果可以看出，隊列中命令的結(jié)果得到返回。
redis 127.0.0.1:6379> exec
1) (integer) 1
2) (integer) 1
2. 事務(wù)中存在失敗的命令：
#開啟一個新的事務(wù)。
redis 127.0.0.1:6379> multi
OK
#設(shè)置鍵a的值為string類型的3。
redis 127.0.0.1:6379> set a 3
QUEUED
#從鍵a所關(guān)聯(lián)的值的頭部彈出元素，由于該值是字符串類型，而lpop命令僅能用于List類型，因此在執(zhí)行exec命令時，該命令將會失敗。
redis 127.0.0.1:6379> lpop a
QUEUED
#再次設(shè)置鍵a的值為字符串4。
redis 127.0.0.1:6379> set a 4
QUEUED
#獲取鍵a的值，以便確認該值是否被事務(wù)中的第二個set命令設(shè)置成功。
redis 127.0.0.1:6379> get a
QUEUED
#從結(jié)果中可以看出，事務(wù)中的第二條命令lpop執(zhí)行失敗，而其后的set和get命令均執(zhí)行成功，這一點是Redis的事務(wù)與關(guān)系型數(shù)據(jù)庫中的事務(wù)之間最為重要的差別。
redis 127.0.0.1:6379> exec
1) OK
2) (error) ERR Operation against a key holding the wrong kind of value
3) OK
4) "4"
3. 回滾事務(wù)：
#為鍵t2設(shè)置一個事務(wù)執(zhí)行前的值。
redis 127.0.0.1:6379> set t2 tt
OK
#開啟一個事務(wù)。
redis 127.0.0.1:6379> multi
OK
#在事務(wù)內(nèi)為該鍵設(shè)置一個新值。
redis 127.0.0.1:6379> set t2 ttnew
QUEUED
#放棄事務(wù)。
redis 127.0.0.1:6379> discard
OK
#查看鍵t2的值，從結(jié)果中可以看出該鍵的值仍為事務(wù)開始之前的值。
redis 127.0.0.1:6379> get t2
"tt"
四、WATCH命令和基于CAS的樂觀鎖：
在Redis的事務(wù)中，WATCH命令可用于提供CAS(check-and-set)功能。假設(shè)我們通過WATCH命令在事務(wù)執(zhí)行之前監(jiān)控了多個Keys，倘若在WATCH之后有任何Key的值發(fā)生了變化，EXEC命令執(zhí)行的事務(wù)都將被放棄，同時返回Null multi-bulk應(yīng)答以通知調(diào)用者事務(wù)執(zhí)行失敗。例如，我們再次假設(shè)Redis中并未提供incr命令來完成鍵值的原子性遞增，如果要實現(xiàn)該功能，我們只能自行編寫相應(yīng)的代碼。其偽碼如下：
val = GET mykey
val = val + 1
SET mykey $val
以上代碼只有在單連接的情況下才可以保證執(zhí)行結(jié)果是正確的，因為如果在同一時刻有多個客戶端在同時執(zhí)行該段代碼，那么就會出現(xiàn)多線程程序中經(jīng)常出現(xiàn)的一種錯誤場景--競態(tài)爭用(race condition)。比如，客戶端A和B都在同一時刻讀取了mykey的原有值，假設(shè)該值為10，此后兩個客戶端又均將該值加一后set回Redis服務(wù)器，這樣就會導(dǎo)致mykey的結(jié)果為11，而不是我們認為的12。為了解決類似的問題，我們需要借助WATCH命令的幫助，見如下代碼：
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
和此前代碼不同的是，新代碼在獲取mykey的值之前先通過WATCH命令監(jiān)控了該鍵，此后又將set命令包圍在事務(wù)中，這樣就可以有效的保證每個連接在執(zhí)行EXEC之前，如果當(dāng)前連接獲取的mykey的值被其它連接的客戶端修改，那么當(dāng)前連接的EXEC命令將執(zhí)行失敗。這樣調(diào)用者在判斷返回值后就可以獲悉val是否被重新設(shè)置成功。
相關(guān)文章
Redis高效查詢大數(shù)據(jù)的實踐與優(yōu)化詳細指南
Redis 是一種高性能的鍵值存儲數(shù)據(jù)庫,廣泛應(yīng)用于緩存,排行榜,計數(shù)器等場景,本文將圍繞如何高效查詢Redis中滿足條件的數(shù)據(jù)展開討論,感興趣的小伙伴可以了解下2025-04-04
這篇文章主要為大家介紹了dubbo服務(wù)在使用redis注冊中心遇到的一系列異常的解決，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步2022-03-03
Windows設(shè)置Redis為開機自啟動的流程步驟
Redis作為當(dāng)前最常用的當(dāng)前緩存技術(shù),基本上Web應(yīng)用中都有使用,所以,每次我們在本地啟動項目前,都必須將Redis服務(wù)端啟動,但是,每次都要去啟動Redis就很麻煩,本文主要就是介紹Windows系統(tǒng)如何配置開機啟動Redis,需要的朋友可以參考下2024-05-05
本文主要介紹了redis?手機驗證碼實現(xiàn)示例，文中通過示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2021-11-11
Redis全文搜索教程之創(chuàng)建索引并關(guān)聯(lián)源數(shù)據(jù)的教程
RediSearch提供了一種簡單快速的方法對 hash 或者 json 類型數(shù)據(jù)的任何字段建立二級索引，然后就可以對被索引的 hash 或者 json 類型數(shù)據(jù)字段進行搜索和聚合操作，這篇文章主要介紹了Redis全文搜索教程之創(chuàng)建索引并關(guān)聯(lián)源數(shù)據(jù),需要的朋友可以參考下2023-12-12
這篇文章主要介紹了redis分布式鎖的8大坑總結(jié)梳理，使用redis的分布式鎖，我們首先想到的可能是setNx命令，文章圍繞setNx命令展開詳細的內(nèi)容介紹，感興趣的小伙伴可以參考一下2022-07-07
這篇文章主要介紹了一文掌握Redis的三種集群方案(小結(jié))，文中通過示例代碼介紹的非常詳細，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-02-02
本文將演示主從復(fù)制如何配置、實現(xiàn)以及實現(xiàn)原理，Redis主從復(fù)制三大策略，全量復(fù)制、部分復(fù)制和立即復(fù)制。2021-05-05
這篇文章主要介紹了redis 限制內(nèi)存使用大小的實現(xiàn)，文中通過示例代碼介紹的非常詳細，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-05-05
這篇文章主要介紹了淺談Redis緩存擊穿、緩存穿透、緩存雪崩的解決方案,緩存是分布式系統(tǒng)中的重要組件，主要解決在高并發(fā)、大數(shù)據(jù)場景下，熱點數(shù)據(jù)訪問的性能問題,需要的朋友可以參考下2023-03-03