快捷導(dǎo)航

Redis保證數(shù)據(jù)不丟失的兩種方法

更新時間：2023年11月27日 11:32:45 作者：Java中文社群

Redis 實現(xiàn)數(shù)據(jù)不丟失的關(guān)鍵在于使用了多種持久化機制,以確保數(shù)據(jù)在內(nèi)存和磁盤之間的持久性,本文給大家介紹了Redis保證數(shù)據(jù)不丟失的兩種方法,持久化和集群運行,我們分別來看它們兩的具體實現(xiàn)細節(jié),感興趣的同學(xué)跟著小編一起來看看吧

1.Redis 持久化

持久化是指將數(shù)據(jù)從內(nèi)存中存儲到持久化存儲介質(zhì)中（如硬盤）的過程，以便在程序重啟或者系統(tǒng)崩潰等情況下，能夠從持久化存儲介質(zhì)中恢復(fù)數(shù)據(jù)。

Redis 4.0 之后支持以下 3 種持久化方案：

RDB（Redis DataBase）持久化：快照方式持久化，將某一個時刻的內(nèi)存數(shù)據(jù)，以二進制的方式寫入磁盤；
AOF（Append Only File）持久化：文件追加持久化，記錄所有非查詢操作命令，并以文本的形式追加到文件中；
混合持久化：RDB + AOF 混合方式的持久化，Redis 4.0 之后新增的方式，混合持久化是結(jié)合了 RDB 和 AOF 的優(yōu)點，在寫入的時候，先把當前的數(shù)據(jù)以 RDB 的形式寫入文件的開頭，再將后續(xù)的操作命令以 AOF 的格式存入文件，這樣既能保證 Redis 重啟時的速度，又能減低數(shù)據(jù)丟失的風(fēng)險。

1.1 RDB 持久化

RDB（Redis Database）是將某一個時刻的內(nèi)存快照（Snapshot），以二進制的方式寫入磁盤的持久化機制。

RDB 持久化機制有以下優(yōu)缺點：

優(yōu)點：

速度快：相對于 AOF 持久化方式，RDB 持久化速度更快，因為它只需要在指定的時間間隔內(nèi)將數(shù)據(jù)從內(nèi)存中寫入到磁盤上。
空間占用小：RDB 持久化會將數(shù)據(jù)保存在一個壓縮的二進制文件中，因此相對于 AOF 持久化方式，它占用的磁盤空間更小。
恢復(fù)速度快：因為 RDB 文件是一個完整的數(shù)據(jù)庫快照，所以在 Redis 重啟后，可以非?？焖俚貙?shù)據(jù)恢復(fù)到內(nèi)存中。
可靠性高：RDB 持久化方式可以保證數(shù)據(jù)的可靠性，因為數(shù)據(jù)會在指定時間間隔內(nèi)自動寫入磁盤，即使 Redis 進程崩潰或者服務(wù)器斷電，也可以通過加載最近的一次快照文件恢復(fù)數(shù)據(jù)。

缺點：

數(shù)據(jù)可能會丟失：RDB 持久化方式只能保證數(shù)據(jù)在指定時間間隔內(nèi)寫入磁盤，因此如果 Redis 進程崩潰或者服務(wù)器斷電，從最后一次快照保存到崩潰的時間點之間的數(shù)據(jù)可能會丟失。
實時性差：因為 RDB 持久化是定期執(zhí)行的，因此從最后一次快照保存到當前時間點之間的數(shù)據(jù)可能會丟失。如果需要更高的實時性，可以使用 AOF 持久化方式。

所以，RDB 持久化方式適合用于對數(shù)據(jù)可靠性要求較高，但對實時性要求不高的場景，如 Redis 中的備份和數(shù)據(jù)恢復(fù)等。

1.2 AOF 持久化

AOF（Append Only File）它是將 Redis 每個非查詢操作命令都追加記錄到文件（appendonly.aof）中的持久化機制。

AOF 持久化機制有以下優(yōu)缺點：

優(yōu)點：

數(shù)據(jù)不容易丟失：AOF 持久化方式會將 Redis 執(zhí)行的每一個寫命令記錄到一個文件中，因此即使 Redis 進程崩潰或者服務(wù)器斷電，也可以通過重放 AOF 文件中的命令來恢復(fù)數(shù)據(jù)。
實時性好：由于 AOF 持久化方式是將每一個寫命令記錄到文件中，因此它的實時性比 RDB 持久化方式更好。
數(shù)據(jù)可讀性強：AOF 持久化文件是一個純文本文件，可以被人類讀取和理解，因此可以方便地進行數(shù)據(jù)備份和恢復(fù)操作。

缺點：

寫入性能略低：由于 AOF 持久化方式需要將每一個寫命令記錄到文件中，因此相對于 RDB 持久化方式，它的寫入性能略低。
占用磁盤空間大：由于 AOF 持久化方式需要記錄每一個寫命令，因此相對于 RDB 持久化方式，它占用的磁盤空間更大。
AOF 文件可能會出現(xiàn)損壞：由于 AOF 文件是不斷地追加寫入的，因此如果文件損壞，可能會導(dǎo)致數(shù)據(jù)無法恢復(fù)。

所以，AOF 持久化方式適合用于對數(shù)據(jù)實時性要求較高，但對數(shù)據(jù)大小和寫入性能要求相對較低的場景，如需要對數(shù)據(jù)進行實時備份的應(yīng)用場景。

1.3 混合持久化

Redis 混合持久化是指將 RDB 持久化方式和 AOF 持久化方式結(jié)合起來使用，以充分發(fā)揮它們的優(yōu)勢，同時避免它們的缺點。

它的優(yōu)缺點如下：

優(yōu)點：混合持久化結(jié)合了 RDB 和 AOF 持久化的優(yōu)點，開頭為 RDB 的格式，使得 Redis 可以更快的啟動，同時結(jié)合 AOF 的優(yōu)點，有減低了大量數(shù)據(jù)丟失的風(fēng)險。

缺點：

實現(xiàn)復(fù)雜度高：混合持久化需要同時維護 RDB 文件和 AOF 文件，因此實現(xiàn)復(fù)雜度相對于單獨使用 RDB 或 AOF 持久化方式要高。
可讀性差：AOF 文件中添加了 RDB 格式的內(nèi)容，使得 AOF 文件的可讀性變得很差；
兼容性差：如果開啟混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。

所以，Redis 混合持久化方式適合用于，需要兼顧啟動速度和減低數(shù)據(jù)丟失的場景。但需要注意的是，混合持久化的實現(xiàn)復(fù)雜度較高、可讀性差，只能用于 Redis 4.0 以上版本，因此在選擇時需要根據(jù)實際情況進行權(quán)衡。

2.Redis 集群

Redis 集群是將原先的單服務(wù)器，變?yōu)榱硕喾?wù)器，這樣 Redis 保存的數(shù)據(jù)也從一臺服務(wù)器變成了多臺服務(wù)器，這樣即使有一臺服務(wù)器出問題了，其他的服務(wù)器還有備份數(shù)據(jù)。所以使用 Redis 集群除了可以保證高可用，還保證了數(shù)據(jù)不丟失。

Redis 集群運行有以下 3 種方案：

主從同步
哨兵模式
Redis Cluster

2.1 主從同步

主從同步 (主從復(fù)制) 是 Redis 高可用服務(wù)的基石，也是多機運行中最基礎(chǔ)的一個。我們把主要存儲數(shù)據(jù)的節(jié)點叫做主節(jié)點 (master)，把其他通過復(fù)制主節(jié)點數(shù)據(jù)的副本節(jié)點叫做從節(jié)點 (slave)，如下圖所示：

在 Redis 中一個主節(jié)點可以擁有多個從節(jié)點，一個從節(jié)點也可以是其他服務(wù)器的主節(jié)點，如下圖所示：

2.2 哨兵模式

主從同步存在一個致命的問題，當主節(jié)點奔潰之后，需要人工干預(yù)才能恢復(fù) Redis 的正常使用。所以我們需要一個自動的工具——Redis Sentinel (哨兵模式) 來把手動的過程變成自動的，讓 Redis 擁有自動容災(zāi)恢復(fù) (failover) 的能力。

哨兵模式如下所示：

小貼士：Redis Sentinel 的最小分配單位是一主一從。

2.3 Redis Cluster

Redis Cluster 是 Redis 3.0 版本推出的 Redis 集群方案，它將數(shù)據(jù)分布在不同的服務(wù)區(qū)上，以此來降低系統(tǒng)對單主節(jié)點的依賴，并且可以大大的提高 Redis 服務(wù)的讀寫性能。 Redis Cluster 架構(gòu)圖如下所示：

從上圖可以看出 Redis 的主從同步只能有一個主節(jié)點，而 Redis Cluster 可以擁有無數(shù)個主從節(jié)點，因此 Redis Cluster 擁有更強大的平行擴展能力，也就是說當 Redis Cluster 擁有兩個主從節(jié)點時，從理論上來講 Redis 的性能相比于主從來說性能提升了兩倍，并且 Redis Cluster 也有自動容災(zāi)恢復(fù)的機制。