1. 我們的這個Redis示例使用AOF進(jìn)行持久化(appendonly)

   appendfsync策略采用的是everysec刷盤。但是AOF隨著時間推移，文件會越來越大，因此，Redis還有一個rewrite策略，實現(xiàn)AOF文件的減肥，但是結(jié)果的冪等的。我們no-appendfsync-on-rewrite的策略是no. 這就會導(dǎo)致在進(jìn)行rewrite操作時，appendfsync會被阻塞。如果當(dāng)前AOF文件很大，那么相應(yīng)的rewrite時間會變長，appendfsync被阻塞的時間也會更長。

• 這不是什么新問題，很多開啟AOF的業(yè)務(wù)場景都會遇到這個問題。解決的辦法有這么幾個：

  • 將no-appendfsync-on-rewrite設(shè)置為yes. 這樣可以避免與appendfsync爭用文件句柄，但是在rewrite期間的AOF有丟失的風(fēng)險。

  • 給當(dāng)前Redis實例添加slave節(jié)點，當(dāng)前節(jié)點設(shè)置為master, 然后master節(jié)點關(guān)閉AOF，slave節(jié)點開啟AOF。這樣的方式的風(fēng)險是如果master掛掉，尚沒有同步到salve的數(shù)據(jù)會丟失。

AOF(append-only file只追加文件)持久化會將執(zhí)行的寫命令追加到AOF文件的末尾。在恢復(fù)數(shù)據(jù)時，只要從頭到尾的執(zhí)行AOF文件中包含的所有寫命令即可（全量復(fù)制數(shù)據(jù)是這樣實現(xiàn)的）

AOF可用配置：

image.png

• 其實主要的就是appendfsync配置項，有三個可選值，
  • always(每次執(zhí)行寫操作都要同步寫入硬盤),
  • everysec(每秒執(zhí)行一次同步),
  • no(讓系統(tǒng)決定何時執(zhí)行同步)。

雖然選擇always可將數(shù)據(jù)丟失減少到最少，但這種策略會對硬盤進(jìn)行大量的寫入操作，處理命令速度受到硬盤限制。建議選擇everysec。

• AOF優(yōu)缺點

  • 優(yōu)點：

    比快照方式可靠，默認(rèn)每秒同步一次，意味著最多丟失一秒的數(shù)據(jù)

  • 缺點：

    相同數(shù)據(jù)集大小，AOF文件會比快照文件大

• AOF文件格式

  一開始以為Redis就是將寫命令原封不動的存儲到AOF文件中，自己試了一下才知道，AOF文件是使用Redis網(wǎng)絡(luò)通訊協(xié)議的格式來保存這些命令。

• 壓縮AOF文件

  Redis可以自動壓縮(也可以叫重寫)AOF文件，用戶也可以通過BGREWRITEAOF命令來壓縮AOF文件。這里的壓縮，不是平時說的壓縮的意思，是指創(chuàng)建一個新的文件來替換舊的文件，兩個文件保存的數(shù)據(jù)狀態(tài)完全一致。如果在本地手動執(zhí)行BGREWRITEAOF命令，可以看到會生成一個temp-rewriteaof-*.aof的臨時文件，在結(jié)束后替換appendonly.aof文件，從而減小appendonly.aof文件的大小。

需要注意的是:

Redis是啟用子進(jìn)程來進(jìn)行AOF文件的壓縮，在這期間主進(jìn)程還是可以繼續(xù)處理請求的，如果這時請求有寫操作就可能導(dǎo)致當(dāng)前數(shù)據(jù)庫與壓縮后的AOF不一致。Redis增加了一個緩存來解決這個問題，主進(jìn)程在接收到新的寫操作命令之后，會將命令寫入現(xiàn)有的AOF文件和緩存中。在子進(jìn)程完成新的AOF文件之后會將緩存的內(nèi)容寫入到新的AOF文件中，并改名覆蓋舊的AOF文件。

RDB快照持久化

image.png

• RDB文件結(jié)構(gòu)：

  RDB文件是一個經(jīng)過壓縮的二進(jìn)制文件，不同類型的鍵值對會采用不同的方式來保存它們。具體的結(jié)構(gòu)我也還沒理清楚。?？梢詤⒖歼@篇文章 http://redisbook.com/preview/rdb/rdb_struct.html

• 創(chuàng)建快照, 創(chuàng)建快照的方式有以下幾種：

  • 客戶端發(fā)送BGSAVE命令。與壓縮AOF文件一樣，Redis會fork出一個子進(jìn)程，由子進(jìn)程負(fù)責(zé)將快照寫入硬盤。
  • 客戶端發(fā)送SAVE命令。Redis會開始創(chuàng)建快照，并且在快照創(chuàng)建完成之前不再處理其他命令。不常使用SAVE命令
  • 在滿足配置的save m n選項時。比如，配置了save 60 1000,會在滿足60秒內(nèi)有1000次寫入的時候開始創(chuàng)建快照。
  • 當(dāng)接收到SHUTDOWN請求時，Redis會執(zhí)行SAVE命令,并且不再執(zhí)行任何其他命令。
  • 當(dāng)從服務(wù)器向主服務(wù)器發(fā)送SYNC命令時，如果主服務(wù)器不是剛剛執(zhí)行過BGSAVE命令,就會開始執(zhí)行BGSAVE來創(chuàng)建快照

• 快照優(yōu)缺點

  • 優(yōu)點：

    • 文件緊湊,適用于做不同版本的數(shù)據(jù)備份
    • 與AOF相比在恢復(fù)大數(shù)據(jù)集時，更快
    • 很方便傳送到另一個數(shù)據(jù)中心

  • 缺點：

    • 一旦Redis出現(xiàn)問題，上一次創(chuàng)建快照之后的數(shù)據(jù)就丟失了