Redis 是否持久化數據？

Question

我知道 Redis 從內存中提供所有數據，但它是否也能在服務器重新啟動后持續存在，以便在服務器重新啟動時將磁盤中的所有數據讀入內存。 或者它總是一個空白存儲，僅在應用程序運行時存儲數據而沒有持久性？

Answer 1

我建議您在http://redis.io/topics/persistence上閱讀有關此內容的信息。 基本上，當您僅使用內存存儲來提高性能時，就會失去保證的持久性。 想象一個場景，您 INSERT 到內存中，但在它被持久化到磁盤之前就斷電了。 會有數據丟失。

Redis 支持所謂的“快照”。 這意味着它將在某些時間點（例如，每整整一小時）對內存中的內容進行完整復制。 當您在兩次快照之間斷電時，您將丟失上次快照和崩潰之間的數據（不一定是停電..）。 Redis 在數據安全與性能之間進行權衡，就像大多數 NoSQL-DB 一樣。

大多數 NoSQL 數據庫遵循在多個節點之間復制的概念，以最大限度地減少這種風險。 Redis 更被認為是一種快速緩存，而不是保證數據一致性的數據庫。 因此，它的用例通常與真實數據庫的用例不同：例如，您可以存儲會話、性能計數器或其中的任何具有無與倫比的性能並且在崩潰時不會真正丟失的東西。 但是處理訂單/購買歷史記錄等被認為是傳統數據庫的工作。

Answer 2

Redis 服務器不時將其所有數據保存到 HDD，從而提供一定程度的持久性。

它在以下情況之一中保存數據：

• 不時自動
• 當您手動調用BGSAVE命令時
• 當 redis 關閉時

但是redis中的數據並不是真正持久化的，因為：

• redis 進程崩潰意味着丟失自上次保存以來的所有更改
• BGSAVE操作只有在你有足夠的空閑RAM時才能執行（額外RAM的數量等於redis DB的大小）

注意： BGSAVE RAM 要求是一個真正的問題，因為 redis 會繼續工作，直到沒有更多的 RAM 可以運行，但它會更早地停止將數據保存到 HDD（大約為 RAM 的 50%）。

有關更多信息，請參閱Redis 持久性。

Answer 3

這是配置問題。 您可以在 Redis 上不保留、部分或完全保留數據。 最佳決策將由項目的技術和業務需求驅動。

根據關於持久性的Redis 文檔，簡而言之，您可以將實例設置為不時或在每次查詢時將數據保存到磁盤中。 它們提供了兩種策略/方法 AOF 和 RDB（閱讀文檔以了解有關 then 的詳細信息），您可以單獨或一起使用每一種。

如果你想要一個“像持久性一樣的 SQL”，他們說：

一般的跡象是，如果您想要與 PostgreSQL 可以提供的數據安全程度相當的數據安全性，則應該同時使用這兩種持久性方法。

Answer 4

答案通常是肯定的，但是更完整的答案實際上取決於您嘗試存儲的數據類型。 一般來說，更完整的簡短答案是：

• Redis 不是持久存儲的最佳選擇，因為它主要關注性能
• Redis 確實更適合可靠的內存中存儲/緩存當前狀態數據，特別是通過為跨多個客戶端/服務器使用的數據提供中央源來實現可擴展性

話雖如此，默認情況下 Redis將定期保留數據快照（顯然這是每 1 分鍾一次，但我尚未驗證這一點 - 下面的文章對此進行了描述，這是一個很好的基本介紹）：

http://qnimate.com/redis-permanent-storage/

---

TL; 博士

來自官方文檔：

• RDB 持久性[默認]以指定的時間間隔執行數據集的時間點快照。
• AOF持久化[需要顯式配置]記錄服務器收到的每個寫操作，在服務器啟動時會再次播放，重建原始數據集。

如果需要，Redis 必須為 AOF 持久性顯式配置，這將導致性能損失以及日志增長。 對於有限數量的數據流的相對可靠的持久性可能就足夠了。

Answer 5

完全可以選擇不持久化。性能更好，但是Redis關閉時所有數據都會丟失。

Redis 有兩種持久化機制：RDB 和 AOF。RDB 使用調度程序全局快照，AOF 將更新寫入類似於 MySql 的僅附加日志文件。

您可以使用其中之一或兩者。當Redis重啟時，它通過讀取RDB文件或AOF文件來構造數據。

Answer 6

許多消息靈通和相對較新的用戶認為 Redis 只是一個緩存，而不是Reliable Persistence的理想選擇。 現實情況是，如今 DB、Cache（以及更多類型）之間的界限已經模糊。

它都是可配置的，作為用戶/工程師，我們可以選擇將其配置為緩存、數據庫（甚至混合）。

每一個選擇都有好處和成本。 這不是 Redis 的例外，但所有著名的分布式系統都提供了配置不同方面（持久性、可用性、一致性等）的選項。 因此，如果您在默認模式下配置 Redis，希望它能神奇地為您提供高度可靠的持久性，那么這是團隊/工程師的錯誤（而不是 Redis 的錯誤）。

我有更多的細節在我的博客中討論這些方面在這里。

另外，這里有一個來自 Redis 本身的鏈接。

Answer 7

該線程中的所有答案都在談論redis持久化數據的可能性： https : //redis.io/topics/persistence （每次寫入（更改）后使用AOF +）。

這是一個很好的鏈接，可以幫助您入門，但顯然沒有向您展示全貌。

---

您真的可以/應該在 Redis 上保留不可恢復的數據/狀態嗎？

Redis 文檔沒有談到：

1. 哪些 redis 提供者支持這個（AOF + 每次寫入后）選項：

• 幾乎沒有 - 雲上的 redis 實驗室不提供此選項。 您可能需要購買內部部署版本的 redis-labs 來支持它。 由於並非所有公司都願意進行內部部署，因此他們會遇到問題。
• 其他 Redis 提供程序根本沒有指定是否支持此選項。 AWS 緩存、Aivan、...
• AOF + 每次寫入后 - 此選項很慢。 您必須在生產硬件上自行測試，看看它是否符合您的要求。
• Redis 企業提供了這個選項，從這個鏈接： https ://redislabs.com/blog/your-cloud-cant-do-that-0-5m-ops-acid-1msec-latency/ 讓我們看看一些基准：

AWS 上的 1x x1.16xlarge 實例 - 他們無法實現低於 2 毫秒的延遲：

其中延遲是從請求的第一個字節到達集群到“寫”響應的第一個字節發送回客戶端的時間測量的

他們在更好的硬盤 (Dell-EMC VMAX) 上進行了額外的基准測試，結果操作延遲小於 1 毫秒 (!!)，從 70K ops/sec（寫密集測試）到 660K ops/sec（讀密集測試）。 相當感人！！！

但它絕對需要（非常）熟練的開發人員來幫助您創建此基礎架構並隨着時間的推移對其進行維護。

2. 有人可能（虛假）爭辯說，如果您有一組 redis 節點（帶有副本），那么現在您擁有完全的持久​​性。 這是虛假聲明：

• 所有數據庫（sql、非 sql、redis...）都有相同的問題 - 例如，在 node1 上運行set x 1 ，在所有其他節點中進行此（或任何）更改需要多長時間. 所以額外的讀取將收到相同的輸出。 好吧，這取決於很多因素和配置。
• 處理多個節點（任何DB類型）中一個鍵的值不一致是一場噩夢。 您可以從 Redis Author (antirez) 閱讀更多相關信息： http ://antirez.com/news/66。 這是在 redis 中存儲狀態的實際 ngihtmare 的簡短示例（+ 解決方案 - WAIT命令以了解其他 redis 節點收到了多少最新更改）：

    def save_payment(payment_id)
        redis.rpush(payment_id,”in progress”) # Return false on exception
        if redis.wait(3,1000) >= 3 then
            redis.rpush(payment_id,”confirmed”) # Return false on exception
            if redis.wait(3,1000) >= 3 then
                return true
            else
                redis.rpush(payment_id,”cancelled”)
                return false
            end
        else
            return false
    end

上面的例子不夠完整，並且有一個真正的問題是提前知道每個時刻實際上有多少（和活着的）節點。

其他數據庫也會有同樣的問題。 也許他們有更好的 API，但問題仍然存在。

據我所知，很多應用程序甚至都沒有意識到這個問題。

總而言之，選擇更多的dbs節點不是一鍵配置。 它涉及更多。

---

總結這項研究，做什么取決於：

1. 你的團隊有多少開發人員（所以這項任務不會減慢你的速度）？
2. 你有熟練的 DevOps 嗎？
3. 您團隊中的分布式系統技能是什么？
4. 花錢買硬件？
5. 是時候投資解決方案了嗎？
6. 而且可能更多...