1. 程式人生 > 其它 >redis事務和鎖機制、持久化操作RDB/AOF

redis事務和鎖機制、持久化操作RDB/AOF

一、Redis事務介紹

Redis事務是一個單獨的隔離操作 :事務中的所有命令都會序列化按順序地執行。事務在執行的過程中,不會被其他客戶端傳送來的命令請求所打斷。
Redis事務的主要作用就是串聯多個命令防止別的命令插隊。

二、Multi、Exec、discard命令

從輸入Multi 命令開始,輸入的命令都會依次進入命令佇列中,但不會執行,直到輸入Exec後, Redis會將之前的命令佇列中的命令依次執行。組隊的過程中可以通過discard來放棄組隊。

 discard取消組隊如下圖:

 如果在multi組隊過程中,發生提示錯誤,在執行exec提交時會發生錯如下圖:

 如果在multi組隊過程中,發生了非提示錯誤

,並不會立馬報錯,而是在exec提交時才會報錯,而且其他命令會正常執行。

三、事務衝突問題  

當多個請求同時操作一個數據時會發生資料錯誤,為了防止這種錯誤,我們可以進行加鎖操作。

1. 樂觀鎖

悲觀鎖(Pessimistic Lock), 顧名思義,就是很悲觀,每次去拿資料的時候都認為別人會修改,所以每次在拿資料的時候都會上鎖,這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制,比如行鎖表鎖等,讀鎖寫鎖等,都是在做操作之前先上鎖。這樣的缺點是效率低

2. 悲觀鎖  

樂觀鎖(Optimistic Lock), 顧名思義,就是很樂觀,每次去拿資料的時候都認為別人不會修改,所以不會上鎖,但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料,可以使用版本號

等機制。樂觀鎖適用於多讀的應用型別,這樣可以提高吞吐量Redis就是利用這種check-and-set機制實現事務的。

3. watch key [key]

在執行multi之前,先執行watch key1 [key2],可以監視一個(或多個) key ,如果在事務執行之前這個(或這些) key 被其他命令所改動,那麼事務將被打斷。

4. unwatch 

取消 WATCH 命令對所有 key 的監視。如果在執行 WATCH 命令之後,EXEC 命令或DISCARD 命令先被執行了的話,那麼就不需要再執行UNWATCH 了。

四、Redis事務三大特性    

1. 單獨的隔離操作

 事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中,不會被其他客戶端傳送來的命令請求所打斷。

2. 沒有隔離級別的概念

 佇列中的命令沒有提交之前都不會實際被執行,因為事務提交前任何指令都不會被實際執行。

3. 不保證原子性  

 事務中如果有一條命令執行失敗,其後的命令仍然會被執行,沒有回滾。

五、持久化操作    

Redis 提供了2個不同形式的持久化方式:RDB(Redis DataBase)、AOF(Append Of File)

1. RDB 

 (1)什麼是RDB

 在指定的時間間隔內將記憶體中的資料集快照寫入磁碟 也就是行話講的Snapshot快照,它恢復時是將快照檔案直接讀到記憶體裡。

 (2)RDB如何進行備份 

 Redis會單獨建立(fork)一個子程序來進行持久化,會先將資料寫入到 一個臨時檔案中,待持久化過程都結束了,再用這個臨時檔案替換上次持久化好的檔案。 整個過程中,主程序是不進行任何IO操作的,這就確保了極高的效能 如果需要進行大規模資料的恢復,且對於資料恢復的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失

 (3)RDB備份  

 先通過config get dir  查詢rdb檔案的目錄

 將*.rdb的檔案拷貝到別的地方

 rdb的恢復

  關閉Redis

  先把備份的檔案拷貝到工作目錄下 cp dump2.rdb dump.rdb

  啟動Redis, 備份資料會直接載入

 (4)RDB的優勢

 適合大規模的資料恢復

 對資料完整性和一致性要求不高更適合使用

 節省磁碟空間

 恢復速度快

 (5)RDB的缺點

 Fork的時候,記憶體中的資料被克隆了一份,大致2倍的膨脹性需要考慮

 雖然Redisfork時使用了寫時拷貝技術,但是如果資料龐大時還是比較消耗效能。

 在備份週期在一定間隔時間做一次備份,所以如果Redis意外down掉的話,就會丟失最後一次快照後的所有修改。

2. AOF  

 (1)什麼是AOF  

 以日誌的形式來記錄每個寫操作(增量儲存),Redis執行過的所有寫指令記錄下來(讀操作不記錄)只許追加檔案但不可以改寫檔案redis啟動之初會讀取該檔案重新構建資料,換言之,redis 重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作

 (2)AOF的持久化過程

1)客戶端的請求寫命令會被append追加到AOF緩衝區內;

2AOF緩衝區根據AOF持久化策略[always,everysec,no]將操作sync同步到磁碟的AOF檔案中;

3AOF檔案大小超過重寫策略或手動重寫時,會對AOF檔案rewrite寫,壓縮AOF檔案容量;

4Redis服務重啟時,會重新load載入AOF檔案中的寫操作達到資料恢復的目的;

 (3)AOF的優勢

 備份機制更穩健,丟失資料概率更低。

 可讀的日誌文字,通過操作AOF穩健,可以處理誤操作。

 (4)AOF的劣勢

 比起RDB佔用更多的磁碟空間。

 恢復備份速度要慢。

 每次讀寫都同步的話,有一定的效能壓力。

 存在個別Bug,造成恢復不能。