引言
終於可以有時間繼續看書，整理自己的見解， 寫下2019年第一篇自己的隨筆。從去年9月份跳槽到新公司後，幾乎天天的加班讓整個人都盲目了，原本計劃好的事情總是會被打亂。都說堅持一件事情很難，特別是寫部落格。確實我由於自己的懶惰以及工作的事情，導致“放棄”了三個的月隨筆博文習慣，希望2019年再接再厲吧；
由於Redis在公司的架構中使用很多，但是大部分人包括我也一開始只是停留在會部署的地步，並沒有深入理解為什麼那麼部署，以及Redis的一些特性，今天參考了一些資料以後，做了關於Redis持久化的一個簡單博文
一、什麼是Redis持久化
簡單來說，就是Redis通過將資料儲存於記憶體或者虛擬記憶體（也是Redis常用的技術），通過某種技術手段將資料儲存於可永久儲存的儲存裝置或媒介中，以此來保證資料完整不丟失、高速訪問資料、快速恢復。
二、Redis持久化的兩種方式
Redis一般通過兩種方式實現持久化：快照方式（RDB模式，預設方式），日誌追加方式（AOF模式）
1. 快照方式（RDB方式）
這種方式有一下幾個特點，顯而易見RDB方式總結起來就是一種將資料以快照方式寫入二進位制檔案中，在間隔時間內全量寫入磁碟的一個過程。它的優缺點也在一下四個特點中體現，
缺點：第一是多少間隔時間的重要性，第二是資料量大的情況下，全量寫入會影響效能
優點：對於恢復操作相對比較簡單，因為全量寫入只需要保證一個二進位制檔案的恢復即可；
（1） 將記憶體中資料以快照的方式寫入二進位制檔案中，預設檔名為dump.rdb
（2） 客戶端使用save/bgsave命令做一次快照持久化（save操作在主執行緒中儲存快照，Redis是用一個主執行緒處理所有的客戶端請求，所以可能會阻塞所有的客戶端請求，不推薦使用）；
（4） 快照方式並不是增量資料，而是全量重新寫入，資料量大的情況下會嚴重影響效能（主要是由於大量IO操作以及主程式不斷fork()子程式去處理持久化工作）。
（5） 快照方式是間隔時間做一次，所以如果redis意外當機的話，就會丟失最後一次快照的後的所有資料。
2. 日誌追加方式(AOF持久化)
Redis會將每一個收到的寫命令都通過write函式追加到檔案中（預設為appendonly.aof），當redis重啟時會通過重新執行檔案中儲存的寫命令來在記憶體中重建整個資料庫的內容。
缺點：相比較RDB而已AOF的檔案相對較大（redis當AOF檔案比較大時，可以重寫），AOF的速度比RDB相對較慢；
優點：採用everysec配置，那麼頂多損失前一秒的資料；不會像RDB那樣損失很多（當然只是相對而言）；
AOF的檔案沒有被重寫的話，比如當我們不小心FULASHALL，現在需要恢復。只需要AOF檔案末尾中去掉該命令，重啟Redis載入即可（即AOF檔案比較容易讀懂，恢復上一個狀態簡單）
（1） 由於OS會在記憶體中快取write的修改，所以並不會立即寫到磁碟上，這樣可能會導致丟失部分修改，可以通過配置來實現強制OS寫到磁碟時機。
a) appendonly yes //啟用日誌追加持久化方式
b) appendfsync always //每次收到寫命令就立即強制寫入磁碟，最慢的，但是保證完全的持久化，不推薦使用
c) appendfsync everysec //每秒鐘強制寫入磁碟一次，在效能和持久化方面做了很好的折中，推薦使用
d) #appendfsync no //完全依賴作業系統，效能最好,持久化沒保證
（2）持久化的檔案會越來越大，比如執行incr test命令100次，最後恢復使用set test 100就夠了，但是這種方式儲存了100條命令，其中99次是多餘的；
（3） 為了（2）中提到的缺點，redis提供了bgrewriteaof命令：redis將記憶體中的資料以命令的方式儲存到臨時檔案中，最後替換原來的持久化日誌檔案。
三、Redis持久化的配置
1. RDB預設方式配置：
# 時間策略：當滿足每900s/300s/60s內至少1/10/10000次寫操作，則會觸發bgsave命令進行持久化，三個策略中只需要滿足其中任何一條即可持久化 save 900 1 save 300 10 save 60 10000 # 檔名稱 dbfilename dump.rdb # 檔案儲存路徑 dir /home/redis/data/ # 如果持久化出錯，主程式是否停止寫入：是為了保證資料的一致性，工作程式（子程式）持久化出錯後，主程式停止寫入請求 stop-writes-on-bgsave-error yes # 是否壓縮 rdbcompression yes # 匯入時是否檢查 rdbchecksum yes
2. AOF日誌追加方式配置：
# 是否開啟aof appendonly yes # 檔名稱 appendfilename "appendonly.aof" # 同步方式，上文已提到 appendfsync everysec # aof重寫操作是否同步，yes則不進行同步，no則同步 no-appendfsync-on-rewrite no # 重寫觸發配置 auto-aof-rewrite-percentage 100 # 當前AOF檔案大小是上次日誌重寫時的AOF檔案大小兩倍時，發生BGREWRITEAOF操作。 auto-aof-rewrite-min-size 64mb # 當前AOF檔案執行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由於檔案尺寸較小導致頻繁的BGREWRITEAOF。 # 載入aof時如果有錯如何處理，忽略最後一條可能存在問題的指令 aof-load-truncated yes # Redis4.0新增RDB-AOF混合持久化格式。 aof-use-rdb-preamble no