redis持久化方式:RDB和AOF

RDB（redis database）

1. 什麼是RDB？
   因爲redis是內存數據庫，斷電時內存數據會丟失，所以RDB就是redis進行持久化的一個機制，將內存中的數據保存在本地磁盤文件，即dump.rdb。

2. 爲什麼要使用RBD？
   就像上面所說的進行持久化，重新啓動redis時會加載dump.rdb中的數據到內存。

3. 怎麼用RDB？
   redis默認啓用RDB，redis的配置文件（windows下面是redis.windows.conf）中的SNAPSHOTTING區域會對RBD進行一些配置，比如

格式：save <seconds> <changes>
#   save ""//當你不想啓用自動更新的時候，可以放開這裏

save 900 1
save 300 10
save 60 10000

意思就是900秒內redis進行了一次更新操作，或者300秒內進行了10次更新操作，60秒內進行了10000次更新操作，那麼將會將內存中的數據fork到磁盤中，也就是dump.rdb。
（tips1：解釋下這裏的fork過程，fork是將redis的主進程完全複製一份，狀態，數據什麼的都相同，然後子進程將數據複製到dump.rdb中，但是這裏就會造成一個問題，假如數據量過大，比如一個班裏做了50人坐滿了，再來50人，那麼redis可能就不行了，在複製期間，主進程是不能進行任何操作的。）

備份過程：

1. Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。
2. 整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能如果需要進行大規模數據的恢復，且對於數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失。
3. fork的作用是複製一個與當前進程一樣的進程。新進程的所有數據（變量、環境變量、程序計數器等）數值都和原進程一致，但是是一個全新的進程，並作爲原進程的子進程

（tips2:文件備份是解決了斷電等軟件異常，但是假如安裝redis的那臺服務器壞掉了，數據一樣會丟失，因此經常會對dump.rdb文件進行備份，且備份到其他機器上，那麼一臺機器壞掉啓用另一臺就好了。）

stop-writes-on-bgsave-error yes

這裏提一下bgsave是異步fork數據到磁盤，主進程可以繼續執行，和上面的save不同。這個配置見詞知意，就是寫數據出錯了立馬停止。

rdbcompression yes

這個是存儲數據時壓縮一下，會造成CPU的佔用。

rdbchecksum yes

對rdb數據進行校驗，大概耗費10%CPU。
（tips：10%！？一聽是很多，但是數據複製一般是在深夜無人的時候，這時候CPU是空閒的，所以一般夠用，這裏不用配置成no，優化這點性能不如再買個redis，因爲程序員的工作是幹不完的，這點不用跟老闆客氣…）

dbfilename dump.rdb

很明顯，就是RDB的文件名。

dir ./

RDB的文件目錄，這裏是相對目錄，和redis.conf在一個目錄。

4. 優點
   1. 適合大規模的數據恢復
      2.全量備份、恢復，只備份最後一次.rdb文件
5. 缺點
   1.在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最後一次快照後的所有修改
   2.fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮

爲了彌補RDB的缺點，誕生了AOF。

AOF(Append Only File)

1. 什麼是AOF？
   存儲redis寫操作指令的文件。
2. 爲什麼用AOF？
   因爲RDB可能丟失數據較多，AOF最壞情況下丟失的數據不超過兩秒。
3. 怎麼用AOF？
   配置文件的APPEND ONLY MODE模塊：

appendonly no					//aof開關，默認是關閉，設置yes打開
appendfilename "appendonly.aof"	//aof文件名
appendfsync everysec				//文件追加方式，有三種：
								1.always 	redis執行一個寫命令，aof文件追加一個命令。
								2.everysec  每秒同步一次命令。
								3.no		不同步命令。
no-appendfsync-on-rewrite no		//當rewrite AOF子進程或RDB子進程正在執行時，Server是否支持fsync，即當新修改的數據寫入AOF文件後，是否將數據刷新到硬盤，設置爲no是最安全的方式，但是會造成阻塞。
官方說明：指定是否在後臺aof文件rewrite期間調用fsync，默認爲no，表示要調用fsync（無論後臺是否有子進程在刷盤）。Redis在後臺寫RDB文件或重寫afo文件期間會存在大量磁盤IO，此時，在某些linux系統中，調用fsync可能會阻塞。

auto-aof-rewrite-percentage 100		//配置重寫aof文件的閾值，默認是超過原文件大小的一倍並且超過64mb，必須同時滿足兩個條件才重寫。
auto-aof-rewrite-min-size 64mb
重寫：當redis執行命令越來越多，那麼aof文件會越來越大，redis會用重寫方式將aof一些命令進行壓縮（比如，連續對一個數據執行了多個 incr 操作，那麼就可以將這些incr操作合成一個set操作），以減小aof文件大小，來減少redis重啓時加載aof文件所需時間。
重寫原理：AOF文件持續增長而過大時，會fork出一個新進程來重寫文件（也是先寫臨時文件再rename），遍歷新進程的內存數據，每條記錄有一個set語句。重寫AOF的操作，並沒有讀取舊的AOF文件，而是將整個內存中的數據用命令的方式重寫了一個新的aof文件，這點和快照有點相似。

5. 優點
   1.靈活的配置同步方式：可以按修改、秒同步，也可以不同步
6. 缺點
   1.相同的數據集的數據而言aof文件遠大於rdb文件，恢復速度慢於rdb
   2.aof運行效率慢於rdb，每秒同步策略較好，不同步效率和rdb相同

下面是帶來的問題：

• 兩者能同時使用嗎？
  可以

• 加載順序？
  先加載aof，再加載rdb

• 如何選擇兩種持久化方式？
  官網建議都開啓，aof比rdb更全，rdb可以作爲一種備用方案。

又爲了彌補aof缺點！產生了redis主從複製！
技術的迭代就是如此呀~