RDB 方式與 AOF 方式的缺點對比

RDB 方式的缺點

如果你希望在 Redis 意外停止工作（例如電源中斷）的情況下丟失的數據最少的話，那么 RDB 不適合你.雖然你可以配置不同的save時間點(例如每隔 5 分鐘并且對數據集有 100 個寫的操作),是 Redis 要完整的保存整個數據集是一個比較繁重的工作,你通常會每隔5分鐘或者更久做一次完整的保存,萬一在 Redis 意外宕機,你可能會丟失幾分鐘的數據。

RDB 需要經常 fork 子進程來保存數據集到硬盤上,當數據集比較大的時候, fork 的過程是非常耗時的,可能會導致 Redis 在一些毫秒級內不能響應客戶端的請求。如果數據集巨大并且 CPU 性能不是很好的情況下,這種情況會持續1秒, AOF 也需要 fork ,但是你可以調節重寫日志文件的頻率來提高數據集的耐久度。

AOF 方式的缺點

對于相同的數據集來說，AOF 文件的體積通常要大于 RDB 文件的體積。

根據所使用的 fsync 策略，AOF 的速度可能會慢于 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。

缺點對比總結

RDB 由于備份頻率不高，所以在回復數據的時候有可能丟失一小段時間的數據，而且在數據集比較大的時候有可能對毫秒級的請求產生影響。

AOF 的文件提及比較大，而且由于保存頻率很高，所以整體的速度會比 RDB 慢一些，但是性能依舊很高。

工作原理

AOF 重寫和 RDB 創建快照一樣，都巧妙地利用了寫時復制機制:

Redis 執行 fork() ，現在同時擁有父進程和子進程。

子進程開始將新 AOF 文件的內容寫入到臨時文件。

對于所有新執行的寫入命令，父進程一邊將它們累積到一個內存緩存中，一邊將這些改動追加到現有 AOF 文件的末尾,這樣樣即使在重寫的中途發生停機，現有的 AOF 文件也還是安全的。

當子進程完成重寫工作時，它給父進程發送一個信號，父進程在接收到信號之后，將內存緩存中的所有數據追加到新 AOF 文件的末尾。

現在 Redis 原子地用新文件替換舊文件，之后所有命令都會直接追加到新 AOF 文件的末尾。

Redis

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。