目錄
一、事務
二、持久化
三、內存淘汰機制
四、過期key處理
一、事務
Redis的事務本質上就是一個批量執行命令的操作。分為三個步驟：
- 開始事務：multi
- 命令入隊：正常輸入命令即可
- 執行事務（依次執行命令）：exec
執行過程中某條命令失敗，事務既不會回滾，也不會停止。
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name Trxcx
QUEUED // 命令入隊而不是立即被執行
127.0.0.1:6379> set age 21
QUEUED
127.0.0.1:6379> incr age
QUEUED
127.0.0.1:6379> incr name // 錯誤的命令正常入隊
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (integer) 22
4) (error) ERR value is not an integer or out of range
5) "Trxcx"
6) "22"
// 即使中間某條命令出錯，前面的命令也沒有回滾，后面的命令也沒有停止。
// 整個事務就是在依次執行這些命令二、持久化
Redis會不定時地將數據持久化到硬盤中，當Redis啟動時，會把硬盤中的數據加載到內存中。
Redis持久化機制共有3種：
1、RDB（Redis DataBase ）：快照方式
將內存中的數據以快照的方式寫入二進制文件，默認為dump.rdb【Redis安裝目錄下】中。觸發RDB持久化的機制分為手動觸發和自動觸發。
- ????????手動觸發：
????????????????①使用save命令。阻塞Redis服務器直到RDB過程完成，數據較多時會長時間阻塞。
????????????????②使用bgsave命令。執行fork指令創建子進程實現RDB持久化。【更建議使用】
- ????????自動觸發：
? ? ? ? ? ? ? ? 使用save進行配置。格式為：save m n。
????????????????表示m秒內數據集存在n次修改則會觸發bgsave。
? ? ? ? ? ? ? ? save 300 10：表示300秒內超過10個key被修改，則觸發RDB過程進行持久化
2、AOF（Append Only File ）：文件追加方式
AOF 日志是一個增量日志文件，它會記錄執行的命令。因此，重啟時再重新執行AOF文件中的命令，就可以達到恢復數據的目的。
Redis默認是不開啟AOF的，通過修改配置文件進行配置。redis 開啟AOF - 簡書 (jianshu.com)
AOF共有3種配置策略，
- appendfsync always：立即同步命令到磁盤，效率慢但保證完全持久化
- appendfsync everysec：每秒同步一次，效率和持久化效果居中【更推薦使用】
- appendfsync no：依賴操作系統，通常每30s同步一次
AOF Rewrite：AOF 文件記錄了每個寫操作的日志，以確保數據持久性。隨著時間的推移，AOF 文件會不斷增大。為了解決這個問題，Redis通過AOF Rewrite 操作創建一個新的 AOF 文件，其中只包含當前數據庫狀態的最小命令集，然后將舊的 AOF 文件替換為這個新文件。
總結：RDB持久化文件更小，啟動速度更快；AOF則在持久化的效果方面更勝一籌。
3、混合持久化方式
Redis同時開啟RDB和AOF，在某時刻T1進行了RDB持久化，在下一次RDB持久化（T3）之前，Redis服務器于T2時刻重啟。
此時恢復數據時，T1之前的數據以 RDB 的形式寫入文件的開頭（全量恢復），T1到T2之間的數據則通過執行AOF文件存儲的操作命令（增量恢復），以此達到速度和持久化效率的平衡。
即以 RDB 作為全量備份，AOF 作為增量備份。
4、持久化機制選擇
- 對安全性要求高：RDB+AOF
- 可以容忍數據丟失：RDB
- 不推薦單獨AOF，可能出現bug。
關于Redis啟動：
AOF和RDB同時存在時優先加載AOF；某一個存在時就加載那一個。
都不存在或加載成功時則啟動成功，存在AOF或者RDB但加載失敗時則啟動失敗。
三、內存淘汰機制
- LRU：Least recently used。最近最少被使用到的key被淘汰。在可選的淘汰對象中，上一次使用時間距離現在最久的key被淘汰。【recently---關注時間】
- LFU：Least Frequently Used。最不經常使用的key被淘汰。在可選的淘汰對象中，使用次數最少的key被淘汰。【Frequently ---關注使用頻次】
- TTL：設置了過期時間且快要過期的key被淘汰。
- 隨機淘汰。
四、過期key處理
- 惰性刪除：訪問key時才去判斷是否過期，過期則直接刪除。【CPU友好，但長期不用的key會一直存在內存中，造成內存浪費】
- 定時刪除：設置定時器，到達過期時間時立即刪除。【CPU不友好，需要額外維護定時器】
- 定期刪除：隔一段時間檢查一次，刪除過期的key。
實際使用：惰性刪除+定期刪除，在CPU使用和內存浪費之間取得平衡。
)
入門)
