redis的持久化和事務

時間 2019-11-20

標籤 redis 持久事務欄目 Redis 简体版

原文原文鏈接

6、redis的持久化

1. RDB

1. 是什麼

在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存裏web

Redis會單首創建（fork）一個子進程來進行持久化，會先將數據寫入到
一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。
整個過程當中，主進程是不進行任何IO操做的，這就確保了極高的性能
若是須要進行大規模數據的恢復，且對於數據恢復的完整性不是很是敏感，那RDB方
式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失。redis

2. fork

就是複製一個與當前進程同樣的進程。新進程的全部數據都和原進程同樣，可是是一個全新的進程，並做爲原進程的子進程數據庫

3.rdb 保存的是dump.rdb文件

4. 如何觸發RDB快照

配置文件中默認的快照配置緩存
1. 冷拷貝後，
2. cp dump.rdb dump1.rdb
命令save或者是bgsave安全
1. save ：只管保存，其餘無論，所有阻塞
2. Bgsave ： redis在後臺異步進行快照操做，同時快照相應客戶端請求，經過lastsave 獲取最後一個成功執行快照的時間
執行flushall命令，也會產生dump.rdb文件，可是裏面是空的服務器

5.如何恢復

將上述備份文件移動到redis安裝目錄並啓動服務
2. config get dir 獲取目錄

5. 優點

適合大規模的數據恢復
對數據完整性和一致性要求不高

6.劣勢

在必定間隔時間作一次備份，若是出現意外，會丟失最後一次備份修改
fork 會致使內存 2倍膨脹性

7. 如何中止

動態全部中止rdb保存規則的辦法
1. redis-cli config set save 「」

2. AOF

1. 是什麼

以日誌的形式來記錄每一個寫操做，將Redis執行過的全部寫指令記錄下來(讀操做不記錄)，app

只許追加文件但不能夠改寫文件，redis啓動之初會讀取該文件從新構建數據，換言之，redis異步

重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工做svg

2. 保存文件

appendonly.aof 文件

3.配置地方在配置文件中能夠找到

4. AOF啓動/修復/恢復

1. 正常恢復

啓動
1. 設置yes
將數據的aof文件複製一份到對應目錄
恢復：重啓redis 從新加載

2. 異常恢復

啓動
1. 設置yes
備份被寫壞的aof文件
修復
1. redis-check-aof --fix進行修復
重啓進行加載

3. rewrite

是什麼性能

AOF採用文件追加方式，文件會愈來愈大爲避免出現此種狀況，新增了重寫機制,

當AOF文件的大小超過所設定的閾值時，Redis就會啓動AOF文件的內容壓縮，

只保留能夠恢復數據的最小指令集.可使用命令bgrewriteaof
重寫原理

AOF文件持續增加而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最後再rename)，

遍歷新進程的內存中數據，每條記錄有一條的Set語句。重寫aof文件的操做，並無讀取舊的aof文件，

而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點相似
觸發機制

Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發

4. 優點

每修改同步： appendfsync
1. always ：同步持久化，每次發生數據變動，都會記錄，性能較差，可是完整性較好
2. everysec ：異步操做，每秒記錄
3. no ：從不一樣步

5. 劣勢

相同的數據集 aof比rdb打，恢復速度也較慢
aof 運行效率慢於rdb ，每秒同步策略效率較好，不一樣步效率相同

3. select who

RDB持久化方式可以在指定的時間間隔能對你的數據進行快照存儲

AOF持久化方式記錄每次對服務器寫的操做,當服務器重啓的時候會從新執行這些

命令來恢復原始的數據,AOF命令以redis協議追加保存每次寫的操做到文件末尾.

Redis還能對AOF文件進行後臺重寫,使得AOF文件的體積不至於過大

只作緩存：若是你只但願你的數據在服務器運行的時候存在,你也能夠不使用任何持久化方式.

1. 建議開啓兩種

在這種狀況下,當redis重啓的時候會優先載入AOF文件來恢復原始的數據,

由於在一般狀況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.

RDB的數據不實時，同時使用二者時服務器重啓也只會找AOF文件。那要不要只使用AOF呢？

做者建議不要，由於RDB更適合用於備份數據庫(AOF在不斷變化很差備份)，

快速重啓，並且不會有AOF可能潛在的bug，留着做爲一個萬一的手段。

具體的性能、安全、效率根據實際狀況，來本身調整

6、事務

1. 是什麼

能夠一次執行多個命令，本質是一組命令的集合。一個事務中的

全部命令都會序列化，按順序地串行化執行而不會被其它命令插入，不準加塞

2. 能幹什麼

一個隊列中，一次性、順序性、排他性的執行一系列命令

3. 具體操做

1. 正常執行

MULTI

set id l2

get id

incr tl

incr tl

get tl

EXEC

2. 放棄事務

MULTI

set name z3

set age 28

incr tl

discard

3.全體連坐

MULTI 

set name z3

get name

incr tl

get tl

set email

EXEC

一個事務都不執行

4. 各作各的

MULTI 

set age 11

incr tl

set email abc@11.com

incr email

EXEC

只運行能執行的事務

5. watch監控

原理

悲觀鎖/樂觀鎖/CAS(Check And Set)

悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認爲別人會修改，因此每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關係型數據庫裏邊就用到了不少這種鎖機制，好比行鎖，表鎖等，讀鎖，寫鎖等，都是在作操做以前先上鎖
 
  樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，因此不會上鎖，可是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣能夠提升吞吐量，
樂觀鎖策略:提交版本必須大於記錄當前版本才能執行更新
 
 
 CAS

例如信用卡可用餘額和欠額
- 若是要改動金額
- 首先監控可用餘額 watch
- 而後開啓事務
- 若是本身的事務不能執行
- 則是版本不一致，有人修改，要unwatch ，解鎖
- 若是本身事務exec 執行了，監控鎖會取消掉
watch 相似樂觀鎖，
watch 能夠監控多個keys，
在exec 執行失敗，同時返回Nullmulti-bulk應答以通知調用者事務執行失敗