兩種持久化方式
Redis有兩種持久化方式，RDB和AOFgit
RDB(Redis DataBase)
RDB默認將數據保存到dump.rdb文件中redis
能夠理解爲將數據備份到磁盤，經過使用該文件就能夠將磁盤中的數據恢復到Redis中app
相關配置操作系統
################################ SNAPSHOTTING ################################ # # 保存 DB 到硬盤: # # save <seconds> <changes> # # 將會在<seconds> 和 <changes>兩個值同時知足時，將DB數據保存到硬盤中 # 其中<seconds> 每多少秒，<changes>是改變的key的數量 # # 在如下的例子中，將會存在以下的行爲 # 當存在最少一個key 變動時，900秒(15分鐘)後保存到硬盤 # 當存在最少10個key變動時，300秒後保存到硬盤 # 當存在最少1000個key變動時，60秒後保存到硬盤 # # 提示: 你能夠禁用以下的全部 save 行 # # 你能夠刪除全部的save而後設置成以下這樣的狀況 # # save "" save 900 1 save 300 10 save 60 10000
在redis-cli中使用save或bgsave都可當即保存數據（bdsave 後臺執行保存數據的動做）日誌
持久化流程code
Redis會單首創建（fork）一個子進程來進行持久化server
子進程會先將數據寫到一個臨時文件中，待持久化過程結束後用這個臨時文件替換掉上次的.rdb文件隊列
持久化過程當中，主進程不進行IO操做。進程
因爲RDB持久化每次會批量持久化數據，因此缺點是最後一次的持久化數據可能丟失。且因爲每次fork時內存中的數據都會被克隆一份，數據會有2倍大小事務
AOF(Append Only File)
AOF將用戶執行增刪改的命令追加到appendonly.aof文件中
文件中存着用戶使用過的除讀操做外的歷史命令的日誌，重啓redis-server後，Redis會讀取並執行該文件中的命令，達到恢復數據的效果
相關配置
############################## APPEND ONLY MODE ############################### # 默認redis使用的是rdb方式持久化，這種方式在許多應用中已經足夠用了。 # 可是redis若是中途宕機，會致使可能有幾分鐘的數據丟失，根據save來策略進行持久化， # Append Only File是另外一種持久化方式，能夠提供更好的持久化特性。 # Redis會把每次寫入的數據在接收後都寫入 appendonly.aof 文件， # 每次啓動時Redis都會先把這個文件的數據讀入內存裏，先忽略RDB文件。 appendonly yes # aof文件名(default: "appendonly.aof") appendfilename "appendonly.aof" # aof持久化策略的配置 # no 表示不執行fsync，由操做系統保證數據同步到磁盤，速度最快。 # always 表示每次寫入都執行fsync，以保證數據同步到磁盤。 # everysec 表示每秒執行一次fsync，可能會致使丟失這1s數據。 appendfsync everysec
缺點
AOF使用的.aof文件的大小遠大於.rdb文件的大小
持久化的使用方式
使用這兩個文件恢復數據的方式：
將他們的文件放在redis目錄下時，重啓redis便可
兩種持久化可同時使用，默認優先使用aof文件恢復數據
==注：若是你執行了fulhall（快樂刪庫）這條命令也會被追加到aof文件中或體如今.rdb文件中==
若是.aof或.rdb文件在備份時被寫壞，致使Redis啓動報錯。使用redis-check-aof --fix <fileName>或redis-check-rdb --fix <fileName>修復文件
使用哪種持久化方式
兩種都用
Redis的事務
一個事務是一條或多條命令的集合，這一條或者多條命令要麼所有執行成功，要麼所有執行失敗。
Redis的支持事務，可是是部分支持。Redis的事務不保證原子性
用關事務的命令
MULTI 開始事務
DISCARD 取消事務
EXEX 執行事務中的命令
WATCH key 監視指定的key，若是==事務開始前==key的值被其餘人修改了，事務執行的時候會被打斷，事務中全部命令執行失敗
UNWATCH 取消對全部key的WATCH
Redis事務的特色
Redis對事務的支持是部分支持，不是徹底支持
- 若是在一個事務中的命令出現錯誤，那麼全部的命令都不會執行
- 若是在一個事務中出現運行錯誤，那麼正確的命令會被執行
單獨的隔離操做：事務中全部的命令多會序列化、按順序地執行。事務在執行的過程當中，不會被其餘客戶端發送來的命令請求所打斷
沒有隔離級別的概念：隊列中的命令沒有提交以前都不會實際的被執行，由於事務提交前任何指令都不會被實際的執行，也就是不存在 「 事務內的查詢要看到事務裏面的更新，在事務外查詢不能看到 」
不保證原子性：Redis 同一個事務中若是有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾
Watch監控
watch在上述事務命令中已經簡單介紹過，這裏再也不贅述
| 鎖的名稱 | 描述 |
|---|---|
| 樂觀鎖 | 樂觀。每次取數據的時候，會認爲數據沒有被修改過 |
| 悲觀鎖 | 悲觀。每次取數據的時候，會認爲數據都被修改過 |
| CAS（Check And Set） | 樂觀鎖的實現 |
加悲觀鎖，就是鎖表。A在用數據，那B就不能用數據。由於悲觀鎖爲防止取的數據是被修改過的而將數據鎖上
加樂觀鎖，像git同樣。A在改數據，結果B在A改以前改過了，那麼A就要先拿到最新的數據而後再修改，提交。和git的pull，push的同樣。由於樂觀鎖不會鎖表，而會在改數據前檢查一下能不能改
watch指令相似樂觀鎖