編程界的小學生
一、原理
下面兩篇博客已經把RDB和AOF講透了。
1、RDB優缺點以及原理
2、AOF優缺點以及原理
二、面試：RDB與AOF哪個快？
1、分析
這道題不嚴謹，因爲不知道他問的是持久化過程哪個快還是說Redis主進程對外提供請求哪個快？（也就是說哪個持久化方式會對主進程影響較大）
2、持久化過程哪個快
那肯定AOF，因爲AOF每次只追加命令，而RDB每次都是全量覆蓋。
3、哪個持久化方式會對主進程影響較大
那肯定是AOF效率低，因爲AOF是串行的，相當於每次處理完命令都要同步的寫入磁盤（當然也看具體策略），而bgsave模式的RDB則是開啓子進程並行的處理這件事，不影響主進程對外提供請求，即使AOF策略開到最容易丟失數據的那種，那也是不定期磁盤操作，這是毫秒級別的。而RDB持久化即使發生CopyOnWrite也只是尋址操作，納秒級別的。
三、面試：能同時存在幾個fork()?
這個在前面兩篇講原理的文章中也有提到，這裏做個總結
- bgsave命令執行期間，client發送的save/bgsave命令會被服務器拒絕，這麼做是因爲如果產生多個子進程同時進行rdb持久化的工作的話會產生競爭條件，造成數據問題已經服務器壓力也會某些條件下過大。
- bgrewriteaof和bgsave能不能同時執行？
1.如果bgsave正在執行，那麼client發送的bgrewriteaof命令會被推遲到bgsave結束後纔得到執行。
2.如果bgrewriteaof正在執行，那麼client發送的bgsave命令將會被服務器拒絕
四、文件格式
1、RDB
1.1、文件在哪
在哪是可配置的，在redis.conf裏有如下配置：
1.2、文件格式
- 以rbd後綴結尾
- 以REDIS開頭的二進制格式，所以體積很小。
cd /var/lib/redis/6379
2、AOF
2.1、文件在哪
還在上面那張圖裏的dia /var/lib/redis/6379文件夾下，名字叫appendonly.aof。
2.2、文件格式
首先需要開啓aof，爲了方便測試再將策略改爲每次執行命令都aof。
appendonly yes
appendfsync always
# 重啓redis
service redis_6379 restart
# 客戶端連接
redis-cli
# 執行命令
set t1 123
這時候會在/var/lib/redis/6379目錄下生成一個aof文件。
來看下aof內容
PS：其實這個格式內容我打算放到實戰篇寫的，想了下，算了，就在這幹吧！
來翻譯下：
首先Redis是以行來劃分，每行以\r\n行結束。每一行都有一個消息頭，消息頭共分爲5種分別如下:
(+) 表示一個正確的狀態信息，具體信息是當前行+後面的字符。
(-) 表示一個錯誤信息，具體信息是當前行－後面的字符。
(*) 表示消息體總共有多少行，不包括當前行,*後面是具體的行數。
($) 表示下一行數據長度，不包括換行符長度\r\n,$後面則是對應的長度的數據。
(: ) 表示返回一個數值，：後面是相應的數字節符。
有了上面的基礎再來看這個aof文件的內容
*2：兩行，也就是往下數兩行，也就是SELECT 0這兩行。意味着選擇第一個庫。
$6：就代表SELECT有6個字節長度。
$1：就代表0的長度是1。
*3：三行，也就是set t1 123
以此類推
五、混合持久化
Redis4.0以及以後新增的內容，很強大。默認開啓，也建議開啓。但具體還要看業務，比如業務就允許數據丟失，那直接RDB就完事了，不需要開AOF，這樣效率還高。如果一點數據都不允許丟失，那隻能RDB+always策略的AOF，換言之，不管怎樣，都建議開啓RDB，RDB可以應對災難性快速恢復。
看這篇文章的【五、RDB-AOF混合持久化】部分就夠了
徹底搞懂Redis持久化之AOF原理
這裏多說下混合持久化的格式。
剛我們看了aof的格式是這樣的，可以發現很佔用空間
那麼我們手動觸發AOF的rewrite功能（注意這裏是混合模式），執行bgrewriteaof命令即可手動觸發
這時候我們會發現文件大小發生了變化，由於我只執行了set t1 123這條命令，本身就很小，所以看不大小佔用問題。數據大的情況很明顯。我們還可以看下文件內容
發現我們的aof文件變成了rdb格式，二進制格式。
我們繼續發送命令set t2 456，然後再觀察aof文件內容，會發現變成混合模式了，前半部分RDB，後半部分AOF，當下次再觸發REWRITE的時候，AOF又會被壓縮成二進制，變成RDB。這就是混合模式。
六、個人公衆號
微信公衆號【Java碼農社區】
