Redis進階-Redis持久化原理

文章目錄

Pre

快照原理

fork( 多進程)

AOF 原理

AOF 重寫

fsync

運維

Redis 4.0 混合持久化

Pre

Redis-16Redis備份(持久化)

Redis 的數據全部在內存里，如果突然宕機，數據就會全部丟失，因此必須有一種機制來保證 Redis 的數據不會因為故障而丟失，這種機制就是 Redis 的持久化機制。

Redis 的持久化機制有兩種

第一種是快照 RDB

第二種是 AOF 日志

快照是一次全量備份，AOF 日志是連續的增量備份。

快照是內存數據的二進制序列化形式，在存儲上非常緊湊，而 AOF 日志記錄的是內存數據修改的指令記錄文本.

AOF 日志在長期的運行過程中會變的無比龐大，數據庫重啟時需要加載 AOF 日志進行指令重放，這個時間就會無比漫長. 所以需要定期進行 AOF 重寫，給 AOF 日志進行瘦身。

快照原理

我們知道 Redis 是單線程程序，這個線程要同時負責多個客戶端套接字的并發讀寫操作和內存數據結構的邏輯讀寫。

在服務線上請求的同時，Redis 還需要進行內存快照，內存快照要求 Redis 必須進行文件 IO 操作，可文件 IO 操作是不能使用多路復用 API。

這意味著單線程同時在服務線上的請求還要進行文件 IO 操作，文件 IO 操作會嚴重拖垮服務器請求的性能。還有個重要的問題是為了不阻塞線上的業務，就需要邊持久化邊響應客戶端請求。持久化的同時，內存數據結構還在改變，比如一個大型的 hash 字典正在持久化，結果一個請求過來把它給刪掉了，還沒持久化完呢，這要怎么搞？

Redis 使用操作系統的多進程 COW(Copy On Write) 機制來實現快照持久化.

Linux-Copy On Write寫時復制機制初探

fork( 多進程)

Redis 在持久化時會調用 glibc 的函數 fork 產生一個子進程，快照持久化完全交給子進程來處理，父進程繼續處理客戶端請求。

子進程剛剛產生時，它和父進程共享內存里面的代碼段和數據段。這時你可以將父子進程想像成一個連體嬰兒，共享身體。這是 Linux 操作系統的機制，為了節約內存資源，所以盡可能讓它們共享起來。在進程分離的一瞬間，內存的增長幾乎沒有明顯變化 .

子進程做數據持久化，它不會修改現有的內存數據結構，它只是對數據結構進行遍歷讀取，然后序列化寫到磁盤中。但是父進程不一樣，它必須持續服務客戶端請求，然后對內存數據結構進行不間斷的修改。

這個時候就會使用操作系統的 COW 機制來進行數據段頁面的分離。數據段是由很多操作系統的頁面組合而成，當父進程對其中一個頁面的數據進行修改時，會將被共享的頁面復制一份分離出來，然后對這個復制的頁面進行修改。這時子進程相應的頁面是沒有變化的，還是進程產生時那一瞬間的數據。

隨著父進程修改操作的持續進行，越來越多的共享頁面被分離出來，內存就會持續增長。但是也不會超過原有數據內存的 2 倍大小。

另外一個 Redis 實例里冷數據占的比例往往是比較高的，所以很少會出現所有的頁面都會被分離，被分離的往往只有其中一部分頁面。每個頁面的大小只有 4K，一個 Redis 實例里面一般都會有成千上萬的頁面。

子進程因為數據沒有變化，它能看到的內存里的數據在進程產生的一瞬間就凝固了，再也不會改變，這也是為什么 Redis 的持久化叫「快照」的原因。接下來子進程就可以非常安心的遍歷數據了進行序列化寫磁盤了.

AOF 原理

AOF 日志存儲的是 Redis 服務器的順序指令序列，

AOF 日志只記錄對內存進行修改的指令記錄。

假設 AOF 日志記錄了自 Redis 實例創建以來所有的修改性指令序列，那么就可以通過對一個空的 Redis 實例順序執行所有的指令，也就是「重放」，來恢復 Redis 當前實例的內存數據結構的狀態。

Redis 會在收到客戶端修改指令后，先進行參數校驗，如果沒問題，就立即將該指令文本存儲到 AOF 日志中，也就是先存到磁盤，然后再執行指令。這樣即使遇到突發宕機，已經存儲到 AOF 日志的指令進行重放一下就可以恢復到宕機前的狀態。

Redis 在長期運行的過程中，AOF 的日志會越變越長。如果實例宕機重啟，重放整個AOF 日志會非常耗時，導致長時間 Redis 無法對外提供服務。所以需要對 AOF 日志瘦身。

AOF 重寫

Redis 提供了 bgrewriteaof 指令用于對 AOF 日志進行瘦身。其原理就是開辟一個子進程對內存進行遍歷轉換成一系列 Redis 的操作指令，序列化到一個新的 AOF 日志文件中。

序列化完畢后再將操作期間發生的增量 AOF 日志追加到這個新的 AOF 日志文件中，追加完畢后就立即替代舊的 AOF 日志文件了，瘦身工作就完成了。

fsync

AOF 日志是以文件的形式存在的，當程序對 AOF 日志文件進行寫操作時，實際上是將內容寫到了內核為文件描述符分配的一個內存緩存中，然后內核會異步將臟數據刷回到磁盤的。

這就意味著如果機器突然宕機，AOF 日志內容可能還沒有來得及完全刷到磁盤中，這個時候就會出現日志丟失。那該怎么辦？

Linux 的 glibc 提供了 fsync(int fd)函數可以將指定文件的內容強制從內核緩存刷到磁盤。只要 Redis 進程實時調用 fsync 函數就可以保證 aof 日志不丟失。但是 fsync 是一個磁盤 IO 操作，它很慢！如果 Redis 執行一條指令就要 fsync 一次，那么 Redis 高性能的地位就不保了.

所以在生產環境的服務器中，Redis 通常是每隔 1s 左右執行一次 fsync 操作，周期 1s是可以配置的。這是在數據安全性和性能之間做了一個折中，在保持高性能的同時，盡可能使得數據少丟失。

Redis 同樣也提供了另外兩種策略，一個是永不 fsync——讓操作系統來決定合適同步磁盤，很不安全，另一個是來一個指令就 fsync 一次——非常慢。但是在生產環境基本不會使用.

運維

快照是通過開啟子進程的方式進行的，它是一個比較耗資源的操作。

1、遍歷整個內存，大塊寫磁盤會加重系統負載

2、AOF 的 fsync 是一個耗時的 IO 操作，它會降低 Redis 性能，同時也會增加系統 IO 負擔

所以通常 Redis 的主節點是不會進行持久化操作，持久化操作主要在從節點進行。從節點是備份節點，沒有來自客戶端請求的壓力，它的操作系統資源往往比較充沛。

但是如果出現網絡分區，從節點長期連不上主節點，就會出現數據不一致的問題，特別是在網絡分區出現的情況下又不小心主節點宕機了，那么數據就會丟失，所以在生產環境要做好實時監控工作，保證網絡暢通或者能快速修復。

另外還應該再增加一個從節點以降低網絡分區的概率，只要有一個從節點數據同步正常，數據也就不會輕易丟失。

Redis 4.0 混合持久化

重啟 Redis 時，我們很少使用 rdb 來恢復內存狀態，因為會丟失大量數據。我們通常使用 AOF 日志重放，但是重放 AOF 日志性能相對 rdb 來說要慢很多，這樣在 Redis 實例很大的情況下，啟動需要花費很長的時間。

Redis 4.0 為了解決這個問題，帶來了一個新的持久化選項——混合持久化。

將 rdb 文件的內容和增量的 AOF 日志文件存在一起。這里的 AOF 日志不再是全量的日志，而是自持久化開始到持久化結束的這段時間發生的增量 AOF 日志，通常這部分 AOF 日志很小。

于是在 Redis 重啟的時候，可以先加載 rdb 的內容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重啟效率因此大幅得到提升。

Redis 數據結構

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

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