目錄

redis實現持久化

RDB

觸發機制-定期方法

定期-手動觸發

save

bgsave

定期-自動觸發

AOF

開啟AOF功能

刷新緩沖區策略

重寫機制

混合持久化

Redis事務

事務相關的命令

MULTI

EXEC

DISCARD

WATCH

---

redis實現持久化

RDB

RDB叫做Redis數據備份文件，也被叫做Redis數據快照。簡單來說就是把內存中的所有數據都記錄到磁盤中。當Redis實例故障重啟后，從磁盤讀取快照文件，恢復數據。快照文件稱為RDB文件，默認是保存在當前運行目錄

觸發機制-定期方法

定期-手動觸發

通過redis客戶端，執行特定的命令，來觸發快照生成

save

執行save的時候，redis就會全力以赴的執行“快照生成”操作，此時就會阻塞redis的其他客戶端的命令（一般不建議使用save）

bgsave

運作流程：

1.執行bgsave命令, Redis 父進程判斷當前進是否存在其他正在執行的子進程，如RDB/AOF子進星，如果存在bgsave命令直接返回。
2.父進程執行fork創建子進程，fork 過程中父進程會阻塞，通過info stats命令查看latest_fork_usec 選項,可以獲取最近一次fork操作的耗時，單位為微秒。
3.父進程fork完成后，bgsave命令返回"Background saving started"信息并不再阻塞父進程，可以繼續響應其他命令。
4.子進程創建RDB文件，根據父進程內存生成臨時快照文件。完成后對原有文件進行原子替換。執行lastsave命令可以獲取最后-次生成RDB的時間，對應info統計的rdb_ last_save_time選項。
5.進程發送信號給父進程表示完成，父進程更新統計信息。

定期-自動觸發

在redis配置文件中，設置一下，讓redis，每隔多長時間/沒產生多少次修改就觸發

RDB問題：不能實時的持久化保存數據，在兩次生成快照之間，實時的數據可能會隨著重啟而丟失

AOF

類似于mysql的binblog，就會把用戶的每個操作，都記錄到文件中。當redis重新啟動的時候，就會讀取這個aof文件中的內容，用來恢復數據。

開啟AOF功能

默認此功能是關閉的，修改配置文件來開啟aof功能

刷新緩沖區策略

1、AOF 機制并非是直接讓工作線程把數據寫入硬盤，而是先寫入一個內存中的緩沖區，積累到一定數量的時候，再統一寫入硬盤；

2、AOF 每次是把新的操作命令順序寫入原有文件的末尾，輸入順序寫入，這樣的方式相比于隨機訪問的速度要快很多的

redis 給出了一些選項，讓我們可以根據實際情況來決定怎么取舍——緩沖區刷新策略：

1、always 每操作一次就保存一次：頻率是最高的，數據可靠性最高，性能最低.

2、everysec 每秒保存一次：頻率低一些，數據可靠性降低，性能會提高.

3、?no 跟隨系統的同步策略：頻率最低，數據可靠性最低，性能是最高的.

重寫機制

此機制能夠針對aof文件進行整理操作，這個整理就是能夠剔除其中的冗余操作，并且合并一些操作，達到給aof文件瘦身的效果

Redis也會在觸發閾值時自動去重寫AO文件，閾值也可以在redis.conf中配置：

流程

混合持久化

結合了rdb和aof的特點，按照aof的方式，每一個請求/操作，都記錄入文件，在觸發aof重寫后，就會把當前內存的狀態按照rdb的二進制格式寫入到新的aof文件中，后續再進行的操作，仍然是按照aof文本的方式追加到文件后面

Redis事務

本質上是在服務器上搞了一個“事務隊列”，每次客戶端在事務中進行了一個操作，都會把命令先發給服務器，放到“事務隊列”中（但是并不會立即執行），而是會在真正收到EXEC命令之后，才真正執行隊列中的所有操作

redis事務和mysql事務的區別：

弱化的原子性：redis沒有“回滾機制”，只能做到這些操作“批量執行”，不能做到“一個失敗就恢復到初始狀態”；

不保證一致性：不涉及“約束”，也沒有回滾。MySQL的一致性體現的是運行事務前和運行后，結果都是合理有效的，不會出現中間非法狀態；

不需要隔離性：也沒有隔離級別，因為不會并發執行事務（redis單線程處理請求）；

不需要持久性：是保存在內存的，是否開啟持久化，是redis-server自己的事情，和事務無關

事務相關的命令

MULTI

開啟事務

EXEC

執行事務

DISCARD

放棄當前事務

WATCH

監控某個key是否在事務執行之前，發生了改變