引言

大家即使沒用過Redis，也應(yīng)該都聽說過Redis的威名。

Redis是一種Nosql類型的數(shù)據(jù)存儲，全稱Remote Dictionary Server，也就是遠程字典服務(wù)器，用過Dictionary的應(yīng)該都知道它是一種鍵值對（Key-Value）的數(shù)據(jù)結(jié)構(gòu)，所以Redis也稱為KV存儲。

Redis的用途十分廣泛，包括幫助網(wǎng)頁快速加載，管理登錄狀態(tài)，更新社交動態(tài)、游戲積分排名、電商搶購秒殺，等等，有點規(guī)模的應(yīng)用后邊都有它的身影。

Redis之所以這么流行，首先是因為它的處理速度特別快，它主要在內(nèi)存中處理數(shù)據(jù)；其次它提供了多種數(shù)據(jù)結(jié)構(gòu)，使用起來比較方便，而且這些數(shù)據(jù)結(jié)構(gòu)的操作時間復(fù)雜度都很優(yōu)秀；最后Redis會將數(shù)據(jù)保存到磁盤中，提供一定的持久性。

但是很多同學(xué)常常對Redis的數(shù)據(jù)安全有所擔(dān)憂，大家經(jīng)常問：Redis能保證數(shù)據(jù)不丟失嗎？怎么做到的？本文會簡單說說Redis的數(shù)據(jù)保護機制，它的好處和局限，以及我們應(yīng)該怎樣設(shè)置、有哪些高級技巧。

Redis面臨的數(shù)據(jù)丟失風(fēng)險

Redis中的數(shù)據(jù)是有可能丟失的。

首先，咱們搞清楚一個概念——數(shù)據(jù)持久性。簡單來說，數(shù)據(jù)持久性就是確保你的數(shù)據(jù)在遇到各種意外情況時，比如斷電、系統(tǒng)崩潰等，之后還能安然無恙的存在。就像是手機，即使沒電了，充上電之后，里面的照片和信息都還在，沒有丟失。

那么，Redis面臨的數(shù)據(jù)丟失風(fēng)險有哪些呢？

上文說到Redis主要在內(nèi)存中操作數(shù)據(jù)，內(nèi)存是一種臨時存儲，一旦斷電（或者硬件故障、軟件錯誤等），內(nèi)存中的數(shù)據(jù)就會煙消云散。有的同學(xué)會說，數(shù)據(jù)不是會保存到硬盤嗎？是的，但是還是可能會有一些數(shù)據(jù)來不及寫入硬盤，這是Redis的持久化機制導(dǎo)致的，下邊會進行詳細(xì)說明。

而且，即使Redis將全部數(shù)據(jù)都及時保存到了硬盤，硬盤出現(xiàn)問題也可能會導(dǎo)致Redis的數(shù)據(jù)丟失。

另外有的同學(xué)會說，我只是在Redis中緩存數(shù)據(jù)，所有的數(shù)據(jù)在數(shù)據(jù)庫中都有完整的記錄。這個問題雖然有點超綱，但是這里還是簡單交代下。這種情況下如果要恢復(fù)的數(shù)據(jù)量比較大，從數(shù)據(jù)庫恢復(fù)數(shù)據(jù)的時間會比較長，這會延長故障的恢復(fù)時間。而且如果系統(tǒng)訪問量比較大，還可能導(dǎo)致緩存穿透的問題，擊垮數(shù)據(jù)庫。

所以，盡管Redis給我們的應(yīng)用帶來了極速體驗，但是如果不采取措施，數(shù)據(jù)丟失的風(fēng)險是實實在在的。下面，我們將探討Redis如何通過各種持久化策略來應(yīng)對這些風(fēng)險，盡量保證數(shù)據(jù)的安全。

基礎(chǔ)策略

保證數(shù)據(jù)不丟失的基礎(chǔ)策略就是使用Redis自帶的持久化機制，Redis提供了兩種主要的數(shù)據(jù)持久化方法：RDB（快照）和AOF（追加文件）。這兩種方法各有千秋，讓我們來詳細(xì)了解一下。

RDB機制

RDB持久化是通過創(chuàng)建數(shù)據(jù)集的快照來工作的，在指定的時間間隔內(nèi)，Redis會自動將內(nèi)存中的數(shù)據(jù)集寫入硬盤的一個文件（通常是dump.rdb）。這就像是給數(shù)據(jù)拍了一張快照，當(dāng)需要的時候可以隨時從這個快照恢復(fù)。

優(yōu)點：

性能高：快照生成時，用到了寫時拷貝技術(shù)，此時Redis主進程只負(fù)責(zé)寫入數(shù)據(jù)，實際保存工作由子進程完成，因此對性能影響較小。

恢復(fù)快：與AOF相比，使用RDB文件恢復(fù)數(shù)據(jù)通常更快。

缺點：

數(shù)據(jù)可能丟失：如果Redis異常停止，那么最后一次快照之后的所有數(shù)據(jù)更改都會丟失。

大數(shù)據(jù)集恢復(fù)時間長：雖然比AOF快，但是如果數(shù)據(jù)集非常大，恢復(fù)過程仍然可能需要較長時間。

AOF機制

AOF持久化通過記錄每個寫操作到一個日志文件中，實現(xiàn)數(shù)據(jù)的持久化。這就像是把每次數(shù)據(jù)變動都先記錄下來，然后再更新到內(nèi)存中，需要恢復(fù)時，按照這個操作日志一步步來就行了。

需要注意AOF記錄也很難做到每個寫操作都先持久化到硬盤中，這是因為硬盤的讀寫速度一般都很慢，比內(nèi)存操作低幾個數(shù)量級，如果每次都先寫到硬盤，Redis也做不到目前的低延遲高并發(fā)。所以寫操作一般都是先緩存一段時間，然后再批量flush到硬盤。

優(yōu)點：

數(shù)據(jù)安全性高：AOF持久化可以配置不同的同步頻率，例如每秒同步，這樣可以在保證性能的同時，減少數(shù)據(jù)丟失的風(fēng)險。

可讀的日志文件：AOF文件是一個純文本文件，可以被人讀懂，便于理解和問題排查。

缺點：

文件體積大：由于記錄了所有寫操作，AOF文件的體積通常會大于RDB文件。

恢復(fù)速度慢：與RDB相比，AOF在恢復(fù)大量數(shù)據(jù)時通常更慢，因為需要重新執(zhí)行所有操作。

配置建議

RDB配置建議

大部分情況下都建議開啟RDB，因為RDB需要的資源相對AOF小很多。如果對數(shù)據(jù)完整性的要求不高，或者能很快的從其它渠道恢復(fù)數(shù)據(jù)，一般只需要開啟RDB就可夠了。

合理設(shè)置快照間隔

Redis的RDB持久化允許我們配置多個不同的快照條件，以適應(yīng)不同的數(shù)據(jù)更新頻率和保證數(shù)據(jù)安全。我們可以在 redis.conf 配置文件中設(shè)置多個快照規(guī)則。以下是一個示例配置，展示了如何根據(jù)數(shù)據(jù)變化的頻繁程度來設(shè)置快照的條件：

# 在900秒內(nèi)如果至少有1個鍵被改變，則進行一次快照
save 900 1
# 在300秒內(nèi)如果至少有10個鍵被改變，則進行一次快照
save 300 10
# 在60秒內(nèi)如果至少有1000個鍵被改變，則進行一次快照
save 60 1000

這樣的配置意味著：

如果數(shù)據(jù)變化不是很頻繁，我們不需要那么頻繁地進行快照保存，以避免不必要的性能開銷。

當(dāng)數(shù)據(jù)變化變得更加頻繁時，我們通過更緊密的快照來減少數(shù)據(jù)丟失的風(fēng)險。

動態(tài)調(diào)整快照規(guī)則

除了在配置文件中靜態(tài)設(shè)置快照規(guī)則外，Redis還提供了命令讓我們可以在運行時動態(tài)調(diào)整快照規(guī)則。使用CONFIG SET命令，我們可以根據(jù)應(yīng)用的當(dāng)前狀態(tài)和需求，動態(tài)地調(diào)整快照條件：

# 動態(tài)設(shè)置快照規(guī)則
redis-cli CONFIG SET save "60 1000 300 10 900 1"

注意事項

性能考量：雖然頻繁的快照可以減少數(shù)據(jù)丟失的風(fēng)險，但也可能會對性能產(chǎn)生影響，特別是在數(shù)據(jù)集很大的情況下。因此，需要根據(jù)實際情況權(quán)衡快照頻率和性能。

監(jiān)控與調(diào)整：建議監(jiān)控Redis的性能指標(biāo)，并根據(jù)實際運行情況調(diào)整快照規(guī)則。隨著業(yè)務(wù)的發(fā)展，可能需要定期回顧和調(diào)整這些設(shè)置。

AOF配置建議

當(dāng)數(shù)據(jù)僅保存在Redis中，或?qū)?shù)據(jù)的丟失難以容忍時，建議開啟AOF。

考慮到性能和數(shù)據(jù)安全，建議設(shè)置為每秒同步一次。這樣既可以保證數(shù)據(jù)的及時性，又不會對性能影響太大。

以下是一個示例配置：

appendfsync everysec

定期重寫AOF

隨著時間的推移，AOF文件可能會變得很大，不僅會占用更多的磁盤空間，而且重啟后或從故障恢復(fù)時處理的會比較慢。緩解這個問題，可以使用Redis提供的定期重寫機制。

在AOF重寫過程中，Redis會創(chuàng)建一個新的AOF文件，這個新文件僅包含重建當(dāng)前數(shù)據(jù)集所需的最小命令集合。例如，如果一系列的INCR命令將某個鍵的值從0遞增到了100，那么在重寫后的AOF文件中可能只會記錄一條SET命令來直接設(shè)置這個鍵為100，從而大大減小文件。

通過 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 參數(shù)可以配置自動重寫的條件。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-percentage：重寫時機：當(dāng)前AOF文件大小相對于上一次重寫后的文件大小的增長百分比。例如，若設(shè)置為100，則表示每當(dāng)AOF文件大小翻倍時，Redis將自動觸發(fā)AOF重寫。

auto-aof-rewrite-min-size：即使?jié)M足了增長百分比條件，Redis也不會立即進行重寫，還需要AOF文件達到一個最小尺寸。只有當(dāng)文件大小超過這個設(shè)定值時，才會真正觸發(fā)重寫。

通過以上配置，在保證Redis性能的同時，數(shù)據(jù)安全性也有了基礎(chǔ)的保證。

高級策略

從對基礎(chǔ)策略的分析中我們了解到即使采用AOF日志，因為寫日志的延遲，數(shù)據(jù)仍存在丟失的可能性。而且即使數(shù)據(jù)都寫入到了硬盤，也無法處理單機硬盤故障導(dǎo)致數(shù)據(jù)丟失的問題。

這一小節(jié)就讓我們來看下處理這個問題的一些高級策略，包括主從架構(gòu)、哨兵系統(tǒng)和集群架構(gòu)。這些策略可以提高數(shù)據(jù)的安全性和可用性。

主從架構(gòu)實現(xiàn)多副本保存

在Redis的主從架構(gòu)中，數(shù)據(jù)會從一個主節(jié)點復(fù)制到一個或多個從節(jié)點。這樣做的好處是，即使主節(jié)點出現(xiàn)問題，我們也可以從從節(jié)點中恢復(fù)數(shù)據(jù)，而且從節(jié)點可以繼續(xù)提供查詢服務(wù)。

工作原理：主節(jié)點負(fù)責(zé)處理所有的寫操作，并將這些操作記錄同步到從節(jié)點。從節(jié)點則可以處理讀請求，分擔(dān)主節(jié)點的讀負(fù)載

優(yōu)點：

數(shù)據(jù)冗余：通過在多個從節(jié)點上保存數(shù)據(jù)副本，提高了數(shù)據(jù)的可靠性。

讀負(fù)載均衡：從節(jié)點可以處理讀請求，幫助分擔(dān)主節(jié)點的讀負(fù)載。

配置示例：

# 從節(jié)點配置 
slaveof <masterip> <masterport>

主節(jié)點無需特別配置，只需正常啟動。從節(jié)點的配置文件中增加slaveof配置，masterip、masterport是主節(jié)點的IP和端口。

哨兵系統(tǒng)實現(xiàn)故障轉(zhuǎn)移

哨兵系統(tǒng)（Sentinel）是一種用于監(jiān)控Redis主從節(jié)點狀態(tài)的系統(tǒng)，能夠在主節(jié)點故障時自動進行故障轉(zhuǎn)移。

工作原理：哨兵通過發(fā)送命令，檢查主從節(jié)點的健康狀態(tài)。如果主節(jié)點不可達，哨兵會自動將其中一個從節(jié)點提升為新的主節(jié)點，并更新其他從節(jié)點以指向新的主節(jié)點。

優(yōu)點：

自動故障轉(zhuǎn)移：提高了系統(tǒng)的可用性，當(dāng)主節(jié)點出現(xiàn)故障時，能夠快速恢復(fù)。

監(jiān)控：哨兵還負(fù)責(zé)監(jiān)控Redis節(jié)點的運行狀態(tài)，提供了一定程度的自動管理。

配置示例：

# 哨兵配置文件 sentinel.conf
sentinel monitor mymaster <masterip> <masterport> 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

sentinel monitor mymaster：這條命令讓哨兵監(jiān)控一個名為 mymaster 的主節(jié)點，其IP和端口分別為 masterip 和 masterport 。數(shù)字2表示當(dāng)至少有兩個哨兵認(rèn)為主節(jié)點不可達時，才會進行故障轉(zhuǎn)移。這是為了避免因為網(wǎng)絡(luò)閃斷導(dǎo)致的誤判。這也告訴我們?nèi)绻枰叩目捎眯?，哨兵進程也要部署多個，一般3個或5個就夠了。

sentinel down-after-milliseconds mymaster 5000：設(shè)置哨兵判斷主節(jié)點為“下線”的時間。例如，這里設(shè)置為5000毫秒（5秒），如果哨兵在這段時間內(nèi)無法達到主節(jié)點，則認(rèn)為主節(jié)點下線。因為各種原因，哨兵可能會出現(xiàn)誤判的問題，多等一會說不定又能訪問主節(jié)點。

sentinel failover-timeout mymaster 60000：設(shè)置故障轉(zhuǎn)移的超時時間，單位是毫秒。在這個例子中，設(shè)置為60000毫秒（60秒）。如果故障轉(zhuǎn)移操作在這段時間內(nèi)沒有完成，則會被取消。

sentinel parallel-syncs mymaster 1：設(shè)置在故障轉(zhuǎn)移后，同時可以有多少個從節(jié)點同時對新的主節(jié)點進行同步。這里設(shè)置為1，意味著一次只有一個從節(jié)點可以同步。在故障轉(zhuǎn)移后，所有從服務(wù)器都需要與新的主服務(wù)器進行全量同步以保證數(shù)據(jù)一致性。由于全量同步會阻塞從節(jié)點，并且可能會消耗較大的網(wǎng)絡(luò)帶寬和CPU資源，所以通過限制并發(fā)同步的從節(jié)點數(shù)量，可以避免過多從節(jié)點同時進行同步帶來的資源壓力過大問題。

集群架構(gòu)實現(xiàn)數(shù)據(jù)冗余

Redis集群通過分片的方式來存儲數(shù)據(jù)，每個分片存儲不同的數(shù)據(jù)。通過多個節(jié)點的協(xié)作，實現(xiàn)數(shù)據(jù)的冗余和分布式存儲。

工作原理：Redis集群將所有的數(shù)據(jù)分為16384個哈希槽，每個節(jié)點負(fù)責(zé)一部分哈希槽?？蛻舳烁鶕?jù)特定的哈希規(guī)則，將數(shù)據(jù)存儲到相應(yīng)的節(jié)點上。

優(yōu)點：

數(shù)據(jù)分片：實現(xiàn)了數(shù)據(jù)的自動分片，便于管理大規(guī)模數(shù)據(jù)。

高可用性：集群中的節(jié)點可以相互備份，即使部分節(jié)點失敗，也不會影響整個集群的可用性。

配置示例： 配置Redis集群涉及到啟動多個Redis實例，可使用redis-cli工具創(chuàng)建集群：

# 啟動Redis實例（假設(shè)啟動6個實例作為示例）
redis-server --port 7000 --cluster-enabled yes --cluster-config-file nodes-7000.conf --cluster-node-timeout 5000 --appendonly yes --appendfilename appendonly-7000.aof --dbfilename dump-7000.rdb --logfile 7000.log
# 重復(fù)上述命令，修改端口為7001-7005
 
# 使用redis-cli創(chuàng)建集群
redis-cli --cluster create <ip1>:7000 <ip2>:7001 <ip3>:7002 <ip4>:7003 <ip5>:7004 <ip6>:7005 --cluster-replicas 1

--cluster-enabled yes：啟用Redis集群模式。

--cluster-config-file nodes-7000.conf：指定集群的配置文件。這個文件由Redis自動維護，記錄了集群中所有節(jié)點的信息。

--cluster-node-timeout 5000：設(shè)置節(jié)點超時時間，單位是毫秒。如果一個節(jié)點在這段時間內(nèi)沒有響應(yīng)，集群會認(rèn)為該節(jié)點已經(jīng)下線。

--appendonly yes：啟用AOF持久化模式。在集群模式下，推薦使用AOF持久化來保證數(shù)據(jù)安全。

--appendfilename appendonly-7000.aof：指定AOF文件的名字。這里根據(jù)不同的端口號，為每個實例指定了不同的AOF文件名，以避免沖突。

--dbfilename dump-7000.rdb：指定RDB文件的名字。同樣地，根據(jù)不同的端口號為每個實例指定了不同的RDB文件名。

--logfile 7000.log：指定日志文件的名字。這有助于在出現(xiàn)問題時進行故障排查。

通過主從架構(gòu)、哨兵系統(tǒng)和集群架構(gòu)，可以有效地實現(xiàn)數(shù)據(jù)的多副本保存、故障轉(zhuǎn)移和數(shù)據(jù)冗余，提高系統(tǒng)的可靠性和可用性，基本上可以避免單機系統(tǒng)的數(shù)據(jù)丟失問題。

跨機房部署

服務(wù)器所在的機房也可能出現(xiàn)問題，比如光纜被挖斷了、空調(diào)系統(tǒng)壞了、機房著火了等實際出現(xiàn)過的狀況，為了解決這些問題，我們還可以通過跨機房的方法來提升Redis的數(shù)據(jù)可靠性和可用性。

• 在不同機房間部署主從復(fù)制架構(gòu)。在一個數(shù)據(jù)中心內(nèi)設(shè)置主節(jié)點，在另一個或多個數(shù)據(jù)中心設(shè)置從節(jié)點。
• Sentinel（哨兵）集群也應(yīng)跨機房部署，以避免單點故障。
• 使用Redis Cluster進行跨機房部署，每個機房都可以有多個分片（shard），并且每個分片的主節(jié)點和從節(jié)點分別位于不同的地理位置，這樣即使一個機房完全不可用，其他機房的副本仍然能夠提供服務(wù)。

跨機房部署時需要自行解決網(wǎng)絡(luò)的通信問題，讓各個節(jié)點之間可以無障礙的相互訪問，機房間最好使用低延遲、高帶寬的專線連接，以加速數(shù)據(jù)同步過程并降低網(wǎng)絡(luò)問題導(dǎo)致的數(shù)據(jù)不一致風(fēng)險。

還有面試中經(jīng)常提及的兩地三中心的多活架構(gòu)，也可以安排上。每個機房都部署一套完整的、獨立處理讀寫請求的Redis集群，并通過分布式鎖或者數(shù)據(jù)同步中間件等技術(shù)保證各個集群間數(shù)據(jù)的一致性。

• 分布式鎖可以采用ZooKeeper、etcd、redis等，確保在多個數(shù)據(jù)中心進行同步更新時，只有一個數(shù)據(jù)中心的Redis集群在給定時間內(nèi)對某個資源擁有寫權(quán)限。
• 數(shù)據(jù)同步中間件主要用于實時或近實時地將一個數(shù)據(jù)中心的寫入操作同步到另一個數(shù)據(jù)中心。可以使用消息隊列、專業(yè)的數(shù)據(jù)同步工具（比如阿里巴巴開源的Canal）等。
• 多活架構(gòu)還要設(shè)計數(shù)據(jù)分片策略、數(shù)據(jù)路由機制以及事務(wù)處理方式，比如根據(jù)地域或者一致性Hash分片來區(qū)分用戶，然后使用客戶端驅(qū)動路由或者網(wǎng)關(guān)路由來把用戶導(dǎo)向不同的機房，最后使用分布式事務(wù)提交數(shù)據(jù)。

多活架構(gòu)比較復(fù)雜，我也沒有實際搞過，這里就不多說了。

其他運維措施

日常運維中的定期檢查和文件備份，雖然平時看起來不起眼，但在關(guān)鍵時刻卻能發(fā)揮巨大作用。

運維工具檢測

就像我們用手表監(jiān)測心率一樣，使用專業(yè)的運維工具可以幫助我們實時監(jiān)控Redis服務(wù)器的狀態(tài)，包括性能指標(biāo)、資源使用情況、可能的瓶頸等。

具體做法：

選擇合適的工具：市面上有許多優(yōu)秀的運維監(jiān)控工具，如Prometheus結(jié)合Grafana、Zabbix等，可以根據(jù)自己的需求和環(huán)境選擇。

定制監(jiān)控項：根據(jù)你的具體需求，定制監(jiān)控項。比如，內(nèi)存使用率、磁盤使用率、命令執(zhí)行延遲、連接數(shù)等，這些都是常見的監(jiān)控指標(biāo)。

設(shè)置告警：設(shè)置閾值，一旦監(jiān)控到的數(shù)據(jù)超過這個閾值，就會觸發(fā)告警。這就像是你的手表在你心率異常時提醒你，幫助你及時發(fā)現(xiàn)并處理問題。

定期備份數(shù)據(jù)

備份就是我們給文件買了一份保險，無論是誤操作還是系統(tǒng)故障，都能夠確保數(shù)據(jù)不會丟失，可以快速恢復(fù)到備份時的狀態(tài)。

具體做法：

定期執(zhí)行：設(shè)定一個合理的備份頻率，比如每天凌晨進行一次。頻率的選擇取決于你的業(yè)務(wù)需求和數(shù)據(jù)變化的頻繁程度。

自動化：利用crontab等工具自動化備份流程，讓備份工作自動化進行，減少人為遺忘的風(fēng)險。

遠程存儲：將備份文件存儲在遠程服務(wù)器或云存儲服務(wù)上。這樣做的好處是，即使本地發(fā)生災(zāi)難性事件，數(shù)據(jù)仍然是安全的。

通過實施這些常規(guī)措施，我們可以大大提高數(shù)據(jù)的安全性和系統(tǒng)的穩(wěn)定性。

總結(jié)

說了這么多，讓我們做一個總結(jié)。

如果你的業(yè)務(wù)對數(shù)據(jù)的完整性要求非常高，建議開啟AOF持久化，并設(shè)置合理的fsync策略（如每秒同步一次）。同時，配合使用主從復(fù)制和哨兵系統(tǒng)，以確保數(shù)據(jù)的高可用性和安全性。

對于讀寫性能有極高要求的場景，可以考慮只使用RDB持久化或者RDB與AOF結(jié)合的方式（數(shù)據(jù)完整性要求高，AOF用于故障恢復(fù)，RDB用于重啟加速）。同時，通過增加從節(jié)點和合理分配讀寫負(fù)載，可以進一步提升性能、提高數(shù)據(jù)安全性。

如果業(yè)務(wù)數(shù)據(jù)量巨大，單個Redis實例難以滿足存儲需求，那么Redis集群是一個不錯的選擇。它通過分片來實現(xiàn)數(shù)據(jù)的分布式存儲，同時保持高可用性。

日常的監(jiān)控和備份也要搞起來，如果服務(wù)和數(shù)據(jù)及其重要，跨機房部署可以提供極大的數(shù)據(jù)安全性和系統(tǒng)穩(wěn)定性。至于傳說中的多活架構(gòu)，不到萬不得已不要輕易嘗試，極為復(fù)雜，成本很高。

最后不要忘了定期演練，搞了這么多的機制到底能不能發(fā)揮作用？有沒有被不小心搞壞，定期演練可以提前發(fā)現(xiàn)問題，及時解決，避免更大的損失。

以上就是淺析Redis如何保證數(shù)據(jù)不丟失的詳細(xì)內(nèi)容，更多關(guān)于Redis數(shù)據(jù)丟失的資料請關(guān)注腳本之家其它相關(guān)文章！