<dfn id="w48us"></dfn><ul id="w48us"></ul>
  • <ul id="w48us"></ul>
  • <del id="w48us"></del>
    <ul id="w48us"></ul>
  • Redis學習筆記:事務詳解

    時間:2020-09-21 12:41:22 讀書筆記 我要投稿

    Redis學習筆記:事務詳解

      一、概述:

    Redis學習筆記:事務詳解

      和眾多其它數據庫一樣,Redis作為NoSQL數據庫也同樣提供了事務機制。在Redis中,MULTI/EXEC/DISCARD/WATCH這四個命令是我們實現事務的基石。相信對有關系型數據庫開發經驗的開發者而言這一概念并不陌生,即便如此,我們還是會簡要的列出Redis中事務的實現特征:

      1). 在事務中的所有命令都將會被串行化的順序執行,事務執行期間,Redis不會再為其它客戶端的請求提供任何服務,從而保證了事物中的所有命令被原子的執行。

      2). 和關系型數據庫中的事務相比,在Redis事務中如果有某一條命令執行失敗,其后的命令仍然會被繼續執行。

      3). 我們可以通過MULTI命令開啟一個事務,有關系型數據庫開發經驗的人可以將其理解為"BEGIN TRANSACTION"語句。在該語句之后執行的命令都將被視為事務之內的操作,最后我們可以通過執行EXEC/DISCARD命令來提交/回滾該事務內的所有操作。這兩個Redis命令可被視為等同于關系型數據庫中的COMMIT/ROLLBACK語句。

      4). 在事務開啟之前,如果客戶端與服務器之間出現通訊故障并導致網絡斷開,其后所有待執行的語句都將不會被服務器執行。然而如果網絡中斷事件是發生在客戶端執行EXEC命令之后,那么該事務中的所有命令都會被服務器執行。

      5). 當使用Append-Only模式時,Redis會通過調用系統函數write將該事務內的所有寫操作在本次調用中全部寫入磁盤。然而如果在寫入的過程中出現系統崩潰,如電源故障導致的宕機,那么此時也許只有部分數據被寫入到磁盤,而另外一部分數據卻已經丟失。Redis服務器會在重新啟動時執行一系列必要的一致性檢測,一旦發現類似問題,就會立即退出并給出相應的錯誤提示。此時,我們就要充分利用Redis工具包中提供的redis-check-aof工具,該工具可以幫助我們定位到數據不一致的錯誤,并將已經寫入的部分數據進行回滾。修復之后我們就可以再次重新啟動Redis服務器了。

      二、相關命令列表:

      命令原型 時間復雜度 命令描述 返回值 MULTI 用于標記事務的開始,其后執行的命令都將被存入命令隊列,直到執行EXEC時,這些命令才會被原子的執行。 始終返回OK EXEC 執行在一個事務內命令隊列中的所有命令,同時將當前連接的狀態恢復為正常狀態,即非事務狀態。如果在事務中執行了WATCH命令,那么只有當WATCH所監控的Keys沒有被修改的前提下,EXEC命令才能執行事務隊列中的所有命令,否則EXEC將放棄當前事務中的所有命令。 原子性的返回事務中各條命令的返回結果。如果在事務中使用了WATCH,一旦事務被放棄,EXEC將返回NULL-multi-bulk回復。 DISCARD 回滾事務隊列中的所有命令,同時再將當前連接的狀態恢復為正常狀態,即非事務狀態。如果WATCH命令被使用,該命令將UNWATCH所有的Keys。 始終返回OK。 WATCHkey [key ...] O(1) 在MULTI命令執行之前,可以指定待監控的Keys,然而在執行EXEC之前,如果被監控的Keys發生修改,EXEC將放棄執行該事務隊列中的所有命令。 始終返回OK。 UNWATCH O(1) 取消當前事務中指定監控的Keys,如果執行了EXEC或DISCARD命令,則無需再手工執行該命令了,因為在此之后,事務中所有被監控的Keys都將自動取消。 始終返回OK。

      三、命令示例:

      1. 事務被正常執行:

      復制代碼 代碼如下:

      #在Shell命令行下執行Redis的客戶端工具。

      /> redis-cli

      #在當前連接上啟動一個新的事務。

      redis 127.0.0.1:6379> multi

      OK

      #執行事務中的第一條命令,從該命令的返回結果可以看出,該命令并沒有立即執行,而是存于事務的命令隊列。

      redis 127.0.0.1:6379> incr t1

      QUEUED

      #又執行一個新的命令,從結果可以看出,該命令也被存于事務的命令隊列。

      redis 127.0.0.1:6379> incr t2

      QUEUED

      #執行事務命令隊列中的所有命令,從結果可以看出,隊列中命令的結果得到返回。

      redis 127.0.0.1:6379> exec

      1) (integer) 1

      2) (integer) 1

      2. 事務中存在失敗的命令:

      復制代碼 代碼如下:

      #開啟一個新的事務。

      redis 127.0.0.1:6379> multi

      OK

      #設置鍵a的值為string類型的3。

      redis 127.0.0.1:6379> set a 3

      QUEUED

      #從鍵a所關聯的值的'頭部彈出元素,由于該值是字符串類型,而lpop命令僅能用于List類型,因此在執行exec命令時,該命令將會失敗。

      redis 127.0.0.1:6379> lpop a

      QUEUED

      #再次設置鍵a的值為字符串4。

      redis 127.0.0.1:6379> set a 4

      QUEUED

      #獲取鍵a的值,以便確認該值是否被事務中的第二個set命令設置成功。

      redis 127.0.0.1:6379> get a

      QUEUED

      #從結果中可以看出,事務中的第二條命令lpop執行失敗,而其后的set和get命令均執行成功,這一點是Redis的事務與關系型數據庫中的事務之間最為重要的差別。

      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. 回滾事務:

      復制代碼 代碼如下:

      #為鍵t2設置一個事務執行前的值。

      redis 127.0.0.1:6379> set t2 tt

      OK

      #開啟一個事務。

      redis 127.0.0.1:6379> multi

      OK

      #在事務內為該鍵設置一個新值。

      redis 127.0.0.1:6379> set t2 ttnew

      QUEUED

      #放棄事務。

      redis 127.0.0.1:6379> discard

      OK

      #查看鍵t2的值,從結果中可以看出該鍵的值仍為事務開始之前的值。

      redis 127.0.0.1:6379> get t2

      "tt"

      四、WATCH命令和基于CAS的樂觀鎖:

      在Redis的事務中,WATCH命令可用于提供CAS(check-and-set)功能。假設我們通過WATCH命令在事務執行之前監控了多個Keys,倘若在WATCH之后有任何Key的值發生了變化,EXEC命令執行的事務都將被放棄,同時返回Null multi-bulk應答以通知調用者事務執行失敗。例如,我們再次假設Redis中并未提供incr命令來完成鍵值的原子性遞增,如果要實現該功能,我們只能自行編寫相應的代碼。其偽碼如下:

      復制代碼 代碼如下:

      val = GET mykey

      val = val + 1

      SET mykey $val

      以上代碼只有在單連接的情況下才可以保證執行結果是正確的,因為如果在同一時刻有多個客戶端在同時執行該段代碼,那么就會出現多線程程序中經常出現的一種錯誤場景--競態爭用(race condition)。比如,客戶端A和B都在同一時刻讀取了mykey的原有值,假設該值為10,此后兩個客戶端又均將該值加一后set回Redis服務器,這樣就會導致mykey的結果為11,而不是我們認為的12。為了解決類似的問題,我們需要借助WATCH命令的幫助,見如下代碼:

      復制代碼 代碼如下:

      WATCH mykey

      val = GET mykey

      val = val + 1

      MULTI

      SET mykey $val

      EXEC

      和此前代碼不同的是,新代碼在獲取mykey的值之前先通過WATCH命令監控了該鍵,此后又將set命令包圍在事務中,這樣就可以有效的保證每個連接在執行EXEC之前,如果當前連接獲取的mykey的值被其它連接的客戶端修改,那么當前連接的EXEC命令將執行失敗。這樣調用者在判斷返回值后就可以獲悉val是否被重新設置成功。

    【Redis學習筆記:事務詳解】相關文章:

    日語學習之全然詳解08-12

    英語學習:感官動詞詳解08-14

    教你利用PHP訪問帶有密碼的Redis11-24

    gre閱讀學習方法詳解09-27

    英語學習:不定詞詳解08-14

    英語學習:分詞構句詳解08-14

    英語學習:句子合成法詳解08-14

    JavaScript學習筆記11-13

    JAVA學習筆記08-29

    Java學習筆記08-13

    主站蜘蛛池模板: 国产精品久久久99| 婷婷国产成人精品一区二| 国产在AJ精品| 国产精品99久久99久久久| 久久丝袜精品中文字幕| 四虎国产精品永久一区 | 亚洲精品白浆高清久久久久久 | 久久精品国产精品亚洲精品| 亚洲国产精品无码专区在线观看| 久久99热这里只有精品国产| 欧美成人精品一级高清片| 精品亚洲成a人片在线观看 | HEYZO无码综合国产精品| 四虎精品成人免费视频| 亚洲国产精品久久久久婷婷软件| 国产精品99久久99久久久| 无码精品人妻一区二区三区人妻斩| 欧美亚洲日本久久精品| 国产精品无码久久综合网| 日本一区精品久久久久影院| 2018国产精华国产精品| 人妻少妇精品视频一区二区三区| 亚洲?V乱码久久精品蜜桃 | 日本精品一区二区三区在线视频 | 色妞ww精品视频7777| 日韩精品毛片| 欧美精品一区二区三区免费观看| 国产啪亚洲国产精品无码 | 99RE6热在线精品视频观看| 亚洲AV日韩精品久久久久久| 亚洲av午夜成人片精品电影| 色偷偷88欧美精品久久久| 久久99精品九九九久久婷婷| 精品国产国产综合精品| 国产精品自在线拍国产手机版| 国产精品高清在线| 国产精品午夜一级毛片密呀 | 亚洲av无码国产精品夜色午夜| 亚洲人成国产精品无码| 亚洲午夜精品久久久久久浪潮 | 国产精品视频网站你懂得|