Redis能保證數據不丟失嗎？
大家即使沒用過Redis，也應該都聽說過Redis的威名。
Redis是一種Nosql類型的數據存儲，全稱Remote Dictionary Server，也就是遠程字典服務器，用過Dictionary的應該都知道它是一種鍵值對（Key-Value）的數據結構，所以Redis也稱為KV存儲。
Redis的用途十分廣泛，包括幫助網頁快速加載，管理登錄狀態，更新社交動態、游戲積分排名、電商搶購秒殺，等等，有點規模的應用后邊都有它的身影。
Redis之所以這么流行，首先是因為它的處理速度特別快，它主要在內存中處理數據；其次它提供了多種數據結構，使用起來比較方便，而且這些數據結構的操作時間復雜度都很優秀；最后Redis會將數據保存到磁盤中，提供一定的持久性。
但是很多同學常常對Redis的數據安全有所擔憂，大家經常問：Redis能保證數據不丟失嗎？怎么做到的？本文會簡單說說Redis的數據保護機制，它的好處和局限，以及我們應該怎樣設置、有哪些高級技巧。
Redis面臨的數據丟失風險
Redis中的數據是有可能丟失的。
首先，咱們搞清楚一個概念——數據持久性。簡單來說，數據持久性就是確保你的數據在遇到各種意外情況時，比如斷電、系統崩潰等，之后還能安然無恙的存在。就像是手機，即使沒電了，充上電之后，里面的照片和信息都還在，沒有丟失。
那么，Redis面臨的數據丟失風險有哪些呢？
上文說到Redis主要在內存中操作數據，內存是一種臨時存儲，一旦斷電（或者硬件故障、軟件錯誤等），內存中的數據就會煙消云散。有的同學會說，數據不是會保存到硬盤嗎？是的，但是還是可能會有一些數據來不及寫入硬盤，這是Redis的持久化機制導致的，下邊會進行詳細說明。
而且，即使Redis將全部數據都及時保存到了硬盤，硬盤出現問題也可能會導致Redis的數據丟失。
另外有的同學會說，我只是在Redis中緩存數據，所有的數據在數據庫中都有完整的記錄。這個問題雖然有點超綱，但是這里還是簡單交代下。這種情況下如果要恢復的數據量比較大，從數據庫恢復數據的時間會比較長，這會延長故障的恢復時間。而且如果系統訪問量比較大，還可能導致緩存穿透的問題，擊垮數據庫。
所以，盡管Redis給我們的應用帶來了極速體驗，但是如果不采取措施，數據丟失的風險是實實在在的。下面，我們將探討Redis如何通過各種持久化策略來應對這些風險，盡量保證數據的安全。
基礎策略
保證數據不丟失的基礎策略就是使用Redis自帶的持久化機制，Redis提供了兩種主要的數據持久化方法：RDB（快照）和AOF（追加文件）。這兩種方法各有千秋，讓我們來詳細了解一下。
RDB機制
RDB持久化是通過創建數據集的快照來工作的，在指定的時間間隔內，Redis會自動將內存中的數據集寫入硬盤的一個文件（通常是dump.rdb）。這就像是給數據拍了一張快照，當需要的時候可以隨時從這個快照恢復。
優點：
- 性能高：快照生成時，用到了寫時拷貝技術，此時Redis主進程只負責寫入數據，實際保存工作由子進程完成，因此對性能影響較小。
- 恢復快：與AOF相比，使用RDB文件恢復數據通常更快。
缺點：
- 數據可能丟失：如果Redis異常停止，那么最后一次快照之后的所有數據更改都會丟失。
- 大數據集恢復時間長：雖然比AOF快，但是如果數據集非常大，恢復過程仍然可能需要較長時間。
AOF機制
AOF持久化通過記錄每個寫操作到一個日志文件中，實現數據的持久化。這就像是把每次數據變動都先記錄下來，然后再更新到內存中，需要恢復時，按照這個操作日志一步步來就行了。
需要注意AOF記錄也很難做到每個寫操作都先持久化到硬盤中，這是因為硬盤的讀寫速度一般都很慢，比內存操作低幾個數量級，如果每次都先寫到硬盤，Redis也做不到目前的低延遲高并發。所以寫操作一般都是先緩存一段時間，然后再批量flush到硬盤。
優點：
- 數據安全性高：AOF持久化可以配置不同的同步頻率，例如每秒同步，這樣可以在保證性能的同時，減少數據丟失的風險。
- 可讀的日志文件：AOF文件是一個純文本文件，可以被人讀懂，便于理解和問題排查。
缺點：
- 文件體積大：由于記錄了所有寫操作，AOF文件的體積通常會大于RDB文件。
- 恢復速度慢：與RDB相比，AOF在恢復大量數據時通常更慢，因為需要重新執行所有操作。
配置建議
RDB配置建議
大部分情況下都建議開啟RDB，因為RDB需要的資源相對AOF小很多。如果對數據完整性的要求不高，或者能很快的從其它渠道恢復數據，一般只需要開啟RDB就可夠了。
合理設置快照間隔
Redis的RDB持久化允許我們配置多個不同的快照條件，以適應不同的數據更新頻率和保證數據安全。我們可以在 redis.conf 配置文件中設置多個快照規則。以下是一個示例配置，展示了如何根據數據變化的頻繁程度來設置快照的條件：
# 在900秒內如果至少有1個鍵被改變，則進行一次快照
save 900 1
# 在300秒內如果至少有10個鍵被改變，則進行一次快照
save 300 10
# 在60秒內如果至少有1000個鍵被改變，則進行一次快照
save 60 1000這樣的配置意味著：
- 如果數據變化不是很頻繁，我們不需要那么頻繁地進行快照保存，以避免不必要的性能開銷。
- 當數據變化變得更加頻繁時，我們通過更緊密的快照來減少數據丟失的風險。
動態調整快照規則
除了在配置文件中靜態設置快照規則外，Redis還提供了命令讓我們可以在運行時動態調整快照規則。使用CONFIG SET命令，我們可以根據應用的當前狀態和需求，動態地調整快照條件：
# 動態設置快照規則
redis-cli CONFIG SET save "60 1000 300 10 900 1"注意事項
- 性能考量：雖然頻繁的快照可以減少數據丟失的風險，但也可能會對性能產生影響，特別是在數據集很大的情況下。因此，需要根據實際情況權衡快照頻率和性能。
- 監控與調整：建議監控Redis的性能指標，并根據實際運行情況調整快照規則。隨著業務的發展，可能需要定期回顧和調整這些設置。
AOF配置建議
當數據僅保存在Redis中，或對數據的丟失難以容忍時，建議開啟AOF。
考慮到性能和數據安全，建議設置為每秒同步一次。這樣既可以保證數據的及時性，又不會對性能影響太大。
以下是一個示例配置：
appendfsync everysec定期重寫AOF
隨著時間的推移，AOF文件可能會變得很大，不僅會占用更多的磁盤空間，而且重啟后或從故障恢復時處理的會比較慢。緩解這個問題，可以使用Redis提供的定期重寫機制。
在AOF重寫過程中，Redis會創建一個新的AOF文件，這個新文件僅包含重建當前數據集所需的最小命令集合。例如，如果一系列的INCR命令將某個鍵的值從0遞增到了100，那么在重寫后的AOF文件中可能只會記錄一條SET命令來直接設置這個鍵為100，從而大大減小文件。
通過 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 參數可以配置自動重寫的條件。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb- auto-aof-rewrite-percentage：重寫時機：當前AOF文件大小相對于上一次重寫后的文件大小的增長百分比。例如，若設置為100，則表示每當AOF文件大小翻倍時，Redis將自動觸發AOF重寫。
- auto-aof-rewrite-min-size：即使滿足了增長百分比條件，Redis也不會立即進行重寫，還需要AOF文件達到一個最小尺寸。只有當文件大小超過這個設定值時，才會真正觸發重寫。
通過以上配置，在保證Redis性能的同時，數據安全性也有了基礎的保證。
高級策略
從對基礎策略的分析中我們了解到即使采用AOF日志，因為寫日志的延遲，數據仍存在丟失的可能性。而且即使數據都寫入到了硬盤，也無法處理單機硬盤故障導致數據丟失的問題。
這一小節就讓我們來看下處理這個問題的一些高級策略，包括主從架構、哨兵系統和集群架構。這些策略可以提高數據的安全性和可用性。
主從架構實現多副本保存
在Redis的主從架構中，數據會從一個主節點復制到一個或多個從節點。這樣做的好處是，即使主節點出現問題，我們也可以從從節點中恢復數據，而且從節點可以繼續提供查詢服務。
工作原理：主節點負責處理所有的寫操作，并將這些操作記錄同步到從節點。從節點則可以處理讀請求，分擔主節點的讀負載。
優點：
- 數據冗余：通過在多個從節點上保存數據副本，提高了數據的可靠性。
- 讀負載均衡：從節點可以處理讀請求，幫助分擔主節點的讀負載。
配置示例：
# 從節點配置
slaveof <masterip> <masterport>主節點無需特別配置，只需正常啟動。從節點的配置文件中增加slaveof配置，masterip、masterport是主節點的IP和端口。
哨兵系統實現故障轉移
哨兵系統（Sentinel）是一種用于監控Redis主從節點狀態的系統，能夠在主節點故障時自動進行故障轉移。
工作原理：哨兵通過發送命令，檢查主從節點的健康狀態。如果主節點不可達，哨兵會自動將其中一個從節點提升為新的主節點，并更新其他從節點以指向新的主節點。
圖片
優點：
- 自動故障轉移：提高了系統的可用性，當主節點出現故障時，能夠快速恢復。
- 監控：哨兵還負責監控Redis節點的運行狀態，提供了一定程度的自動管理。
配置示例：
# 哨兵配置文件 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：這條命令讓哨兵監控一個名為 mymaster 的主節點，其IP和端口分別為 masterip 和 masterport 。數字2表示當至少有兩個哨兵認為主節點不可達時，才會進行故障轉移。這是為了避免因為網絡閃斷導致的誤判。這也告訴我們如果需要更高的可用性，哨兵進程也要部署多個，一般3個或5個就夠了。
- sentinel down-after-milliseconds mymaster 5000：設置哨兵判斷主節點為“下線”的時間。例如，這里設置為5000毫秒（5秒），如果哨兵在這段時間內無法達到主節點，則認為主節點下線。因為各種原因，哨兵可能會出現誤判的問題，多等一會說不定又能訪問主節點。
- sentinel failover-timeout mymaster 60000：設置故障轉移的超時時間，單位是毫秒。在這個例子中，設置為60000毫秒（60秒）。如果故障轉移操作在這段時間內沒有完成，則會被取消。
- sentinel parallel-syncs mymaster 1：設置在故障轉移后，同時可以有多少個從節點同時對新的主節點進行同步。這里設置為1，意味著一次只有一個從節點可以同步。在故障轉移后，所有從服務器都需要與新的主服務器進行全量同步以保證數據一致性。由于全量同步會阻塞從節點，并且可能會消耗較大的網絡帶寬和CPU資源，所以通過限制并發同步的從節點數量，可以避免過多從節點同時進行同步帶來的資源壓力過大問題。
集群架構實現數據冗余
Redis集群通過分片的方式來存儲數據，每個分片存儲不同的數據。通過多個節點的協作，實現數據的冗余和分布式存儲。
工作原理：Redis集群將所有的數據分為16384個哈希槽，每個節點負責一部分哈希槽。客戶端根據特定的哈希規則，將數據存儲到相應的節點上。
優點：
- 數據分片：實現了數據的自動分片，便于管理大規模數據。
- 高可用性：集群中的節點可以相互備份，即使部分節點失敗，也不會影響整個集群的可用性。
配置示例： 配置Redis集群涉及到啟動多個Redis實例，可使用redis-cli工具創建集群：
# 啟動Redis實例（假設啟動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
# 重復上述命令，修改端口為7001-7005
# 使用redis-cli創建集群
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自動維護，記錄了集群中所有節點的信息。
- --cluster-node-timeout 5000：設置節點超時時間，單位是毫秒。如果一個節點在這段時間內沒有響應，集群會認為該節點已經下線。
- --appendonly yes：啟用AOF持久化模式。在集群模式下，推薦使用AOF持久化來保證數據安全。
- --appendfilename appendonly-7000.aof：指定AOF文件的名字。這里根據不同的端口號，為每個實例指定了不同的AOF文件名，以避免沖突。
- --dbfilename dump-7000.rdb：指定RDB文件的名字。同樣地，根據不同的端口號為每個實例指定了不同的RDB文件名。
- --logfile 7000.log：指定日志文件的名字。這有助于在出現問題時進行故障排查。
通過主從架構、哨兵系統和集群架構，可以有效地實現數據的多副本保存、故障轉移和數據冗余，提高系統的可靠性和可用性，基本上可以避免單機系統的數據丟失問題。
跨機房部署
服務器所在的機房也可能出現問題，比如光纜被挖斷了、空調系統壞了、機房著火了等實際出現過的狀況，為了解決這些問題，我們還可以通過跨機房的方法來提升Redis的數據可靠性和可用性。
- 在不同機房間部署主從復制架構。在一個數據中心內設置主節點，在另一個或多個數據中心設置從節點。
- Sentinel（哨兵）集群也應跨機房部署，以避免單點故障。
- 使用Redis Cluster進行跨機房部署，每個機房都可以有多個分片（shard），并且每個分片的主節點和從節點分別位于不同的地理位置，這樣即使一個機房完全不可用，其他機房的副本仍然能夠提供服務。
跨機房部署時需要自行解決網絡的通信問題，讓各個節點之間可以無障礙的相互訪問，機房間最好使用低延遲、高帶寬的專線連接，以加速數據同步過程并降低網絡問題導致的數據不一致風險。
還有面試中經常提及的兩地三中心的多活架構，也可以安排上。每個機房都部署一套完整的、獨立處理讀寫請求的Redis集群，并通過分布式鎖或者數據同步中間件等技術保證各個集群間數據的一致性。
- 分布式鎖可以采用ZooKeeper、etcd、redis等，確保在多個數據中心進行同步更新時，只有一個數據中心的Redis集群在給定時間內對某個資源擁有寫權限。
- 數據同步中間件主要用于實時或近實時地將一個數據中心的寫入操作同步到另一個數據中心。可以使用消息隊列、專業的數據同步工具（比如阿里巴巴開源的Canal）等。
- 多活架構還要設計數據分片策略、數據路由機制以及事務處理方式，比如根據地域或者一致性Hash分片來區分用戶，然后使用客戶端驅動路由或者網關路由來把用戶導向不同的機房，最后使用分布式事務提交數據。
多活架構比較復雜，我也沒有實際搞過，這里就不多說了。
其他運維措施
日常運維中的定期檢查和文件備份，雖然平時看起來不起眼，但在關鍵時刻卻能發揮巨大作用。
運維工具檢測
就像我們用手表監測心率一樣，使用專業的運維工具可以幫助我們實時監控Redis服務器的狀態，包括性能指標、資源使用情況、可能的瓶頸等。
具體做法：
- 選擇合適的工具：市面上有許多優秀的運維監控工具，如Prometheus結合Grafana、Zabbix等，可以根據自己的需求和環境選擇。
- 定制監控項：根據你的具體需求，定制監控項。比如，內存使用率、磁盤使用率、命令執行延遲、連接數等，這些都是常見的監控指標。
- 設置告警：設置閾值，一旦監控到的數據超過這個閾值，就會觸發告警。這就像是你的手表在你心率異常時提醒你，幫助你及時發現并處理問題。
定期備份數據
備份就是我們給文件買了一份保險，無論是誤操作還是系統故障，都能夠確保數據不會丟失，可以快速恢復到備份時的狀態。
具體做法：
- 定期執行：設定一個合理的備份頻率，比如每天凌晨進行一次。頻率的選擇取決于你的業務需求和數據變化的頻繁程度。
- 自動化：利用crontab等工具自動化備份流程，讓備份工作自動化進行，減少人為遺忘的風險。
- 遠程存儲：將備份文件存儲在遠程服務器或云存儲服務上。這樣做的好處是，即使本地發生災難性事件，數據仍然是安全的。
通過實施這些常規措施，我們可以大大提高數據的安全性和系統的穩定性。
總結
說了這么多，讓我們做一個總結。
如果你的業務對數據的完整性要求非常高，建議開啟AOF持久化，并設置合理的fsync策略（如每秒同步一次）。同時，配合使用主從復制和哨兵系統，以確保數據的高可用性和安全性。
對于讀寫性能有極高要求的場景，可以考慮只使用RDB持久化或者RDB與AOF結合的方式（數據完整性要求高，AOF用于故障恢復，RDB用于重啟加速）。同時，通過增加從節點和合理分配讀寫負載，可以進一步提升性能、提高數據安全性。
如果業務數據量巨大，單個Redis實例難以滿足存儲需求，那么Redis集群是一個不錯的選擇。它通過分片來實現數據的分布式存儲，同時保持高可用性。
日常的監控和備份也要搞起來，如果服務和數據及其重要，跨機房部署可以提供極大的數據安全性和系統穩定性。至于傳說中的多活架構，不到萬不得已不要輕易嘗試，極為復雜，成本很高。
最后不要忘了定期演練，搞了這么多的機制到底能不能發揮作用？有沒有被不小心搞壞，定期演練可以提前發現問題，及時解決，避免更大的損失。
