Redis持久化： .rdb 和 .aof
Redis爲什麼要持久化? Redis是保存在內存中，斷電數據消失。爲了能夠在重啓後也保留數據，則需要對數據持久化。
Redis自帶了兩種持久化方式：RDB和AOF。
在指定的時間間隔內（可以在service.conf 中找關鍵字：save “”），將內存的數據集快照（snapshot）寫入磁盤,數據恢復時，是直接讀取rdb文件到內存。
整個過程，主進程不進行IO操作，確保了高性能。
我們知道save “” 是有多少秒內多少次操作才進行數據集快照保存，所以會存在恰巧不滿足條件的那一部分時間的數據沒有持久化，從而丟失的可能。如果數據量很大，而且對數據的完整性恢復不那麼敏感，那麼RDB方式要比AOF方式要高效。
沒有修改默認配置的話，.rdb文件是在我們的安裝目錄（可以查看redis.conf文件
# The filename where to dump the DB
# rdb的文件名
dbfilename dump.rdb
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
# rdb文件保存的路徑
dir ./
）
觸發持久化的條件：
- save條件滿足，自動觸發RDB規則
- 執行flushall命令，也會立即觸發RDB規則
- 退出redis，也觸發RDB規則
RDB文件存在，但是提示不能登陸，有可能是文件損毀，如何修復？
在我們的安裝目錄，可以看到裏面有個 redis-check-rdb,啓動它，這是redis自帶的修復工具。
從其他地方移過來的RDB文件應該放在哪，才能恢復文件裏的數據到內存？
在Redis客戶端執行
config get dir
得到一個路徑，放在這個路徑裏面就行。
RDB的優缺點：
-
優點：1 適合大規模數據的恢復 2 對數據的完整性要求不高
-
缺點：1 需要一定的時間間隔進程進行操作，如果意外斷電，最後一次修改的數據則丟失。 2 fork子進程的時候，會佔用一定內存空間。
-
AOF(Append Only File)
AOF是什麼，是一個文件，可以文本編輯器查看，把我們所有的命令記錄下來，數據恢復的時候，再把這個文件全部執行一遍。
通過service.conf中
# Please check http://redis.io/topics/persistence for more information.
# 默認是不開啓aof模式的，默認是RDB持久化，大部分情況下，rdb夠用
appendonly no
# The name of the append only file (default: "appendonly.aof")
# aof持久化的文件名
appendfilename "appendonly.aof"
設置爲yes開啓，然後重啓生效
持久化規則：
#每次持久化都會sync，消耗性能
# appendfsync always
#每秒執行sync，可能會丟失這一秒的數據
appendfsync everysec
# 永不sync，這個時候操作系統自己去執行同步，速度最快！
# appendfsync no
文件存儲大小
#改爲yes後，文件會無限變大
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
#大於64M，則追加一個文件
auto-aof-rewrite-min-size 64mb
修復AOF文件
執行redis-check-aof
優缺點：
- 優點：設置爲每一次修改都同步，文件完整性最好；每秒都同步，可能會丟失一秒數據；從不同步，效率最高。
- 缺點：AOF文件大於RDB文件，修復速度慢於RDB；運行速度比RDB慢
總結：
-
RDB持久化能夠在指定時間間隔對數據進行數據集快照存儲。
-
AOF持久化每次記錄寫操作，當服務器重啓的時候，會重新執行這些命令。
-
如果單純作爲緩存，希望只是服務器運行的時候這些存在，運行重啓後redis沒有數據，那麼可以不用任何持久化。
-
同時開啓RDB和AOF：這種情況會優先載入AOF文件來恢復數據，因爲一般情況AOF比RDB存儲的更詳細；但是仍推薦用RDB恢復，因爲RDB對於大數據量的恢復有優勢（速度快，存儲量多）
-
性能建議（摘自狂神說的文章，我還需要消化一下）
因爲RDB文件只用作後備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠
了，只保留 save 900 1 這條規則。
如果Enable AOF ，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啓動腳本較簡單隻load自
己的AOF文件就可以了，代價一是帶來了持續的IO，二是AOF rewrite 的最後將 rewrite 過程中產
生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該儘量減少AOF rewrite
的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上，默認超過原大小100%大小重
寫可以改到適當的數值。
如果不Enable AOF ，僅靠 Master-Slave Repllcation 實現高可用性也可以，能省掉一大筆IO，也
減少了rewrite時帶來的系統波動。代價是如果Master/Slave 同時倒掉，會丟失十幾分鐘的數據，
啓動腳本也要比較兩個 Master/Slave 中的 RDB文件，載入較新的那個，微博就是這種架構。