Redis 經常被本能地拿來用，「直接加 Redis 就對了」，彷彿只要有它就能解決效能問題。它確實是後端工程師工具箱中最有用的工具之一，但要善用 Redis，首先要了解它真正的本質：一個記憶體內資料結構儲存庫，而不只是快取。一旦你把它視為能快速儲存真實資料結構的工具，它能乾淨解決的各種問題（快取、速率限制、佇列、工作階段、排行榜、鎖）就不再是雜七雜八的集合，而是一套概念的多種應用。

這是 Redis 大師班的第一篇文章，建立在 PostgreSQL 系列之上：Redis 通常是與像 Postgres 這類主要資料庫並存，而不是取代它。

記憶體內是核心重點

Redis 將資料保留在 RAM 中。這個單一事實解釋了它大部分的特徵。從記憶體讀取的速度比從磁碟讀取快上好幾個數量級，因此 Redis 的操作通常能在不到一毫秒的時間內完成，單一執行個體也能處理極高的請求量。這也是為什麼它成為「熱路徑」（hot path）上預設選擇的原因——資料庫往返一次的速度對這種情境來說太慢了。

代價是 RAM 比磁碟小且昂貴，而且具有揮發性。Redis 透過我們稍後會介紹的持久化選項來處理耐用性，但一開始的心理模型應該是：Redis 之所以快是因為它在記憶體中，你應該將它用在需要快速存取的資料上，而不是作為所有資料的永久存放處。

它是資料結構儲存庫，而不是鍵值 Blob

常見的誤解是認為 Redis 只是簡單的鍵值儲存庫，輸入字串、輸出字串。事實遠不止如此。Redis 將真正的資料結構作為值來儲存，每種結構都有自己的指令：

  • 字串（Strings）：用於簡單值、計數器與快取的 Blob。
  • 雜湊（Hashes）：用於帶有欄位的物件，例如使用者紀錄。
  • 串列（Lists）：用於有序序列與簡單佇列。
  • 集合（Sets）：用於唯一集合與成員檢查。
  • 排序集合（Sorted sets）：用於排行榜與優先佇列等排序資料。
  • 此外還有串流（streams）、位元圖（bitmaps）、HyperLogLog、地理解析索引，以及機率性結構。

這正是 Redis 多功能的原因。排行榜就是排序集合；速率限制器就是帶有過期時間的計數器；工作佇列就是串列或串流。這些都是 Redis 已經用原子操作實作的資料結構，因此你無需自行實作就能獲得這些行為。本系列的其餘部分主要是介紹這些結構及其所支援的模式。

Redis 擅長的應用

強力的使用情境都有共通特徵：快速存取暫時性資料，或是權威資料的低成本重建副本。

  • 快取（Caching）：儲存昂貴查詢或運算的結果，避免重複執行。這是最常見的用法，也是本系列中一個完整的模組主題。
  • 工作階段儲存（Session storage）：使用者工作階段需要每次請求都能快速讀取，但不適合放在主要資料庫中。
  • 速率限制（Rate limiting）：計算每個使用者在時間視窗內的請求次數，這正是 Redis 擅長的「帶有過期時間的計數器」。
  • 佇列與工作處理（Queues and job processing）：串列與串流是許多任務佇列系統的基礎。
  • 即時功能（Real-time features）：排行榜、計數器、發布/訂閱訊息、線上狀態等，都需要亞毫秒級的更新。
  • 分散式協調（Distributed coordination）：跨多個應用伺服器的鎖與信號量。

Redis 不適合的應用

了解 Redis 的界限與了解它的用途同樣重要。以下情況 Redis 不是正確的工具：

  • 你需要將它作為關鍵資料的主要資料庫。 Redis 雖然支援持久化，但其設計優先考量速度，而非關聯式資料庫的耐用性保證。訂單、付款與使用者帳戶等真實資料來源，應該使用像 Postgres 這類資料庫，並將 Redis 作為前置的快速層。
  • 資料量無法放入記憶體。 Redis 將所有資料放在 RAM 中，如果資料集遠大於你的記憶體預算，就不適合使用 Redis，此時磁碟型資料庫通常是更好的選擇。
  • 你需要複雜查詢、聯結或臨時報表。 Redis 沒有 SQL、沒有聯結、沒有查詢規劃器。它在自己資料結構支援的存取模式上非常快速，但不適合進行任意查詢。

重複的原則是：Redis 輔助主要資料庫，而不是取代它。Postgres 擁有耐用、可查詢的真實資料來源；Redis 則讓熱路徑變得更快。

值得帶走的心理模型

把 Redis 想像成一個裝滿快速、原子資料結構的盒子，這些結構存在於記憶體中，放在你的真實資料庫旁邊。當問題能對應到其中一種結構（計數器、排序集合、佇列、快取值）時，Redis 就能乾淨且快速地解決它。當問題需要耐用性、複雜查詢，或資料量超過記憶體容量時，那就是資料庫的工作。大多數設計良好的系統都會同時使用兩者，各取所長。

有了這個框架，本系列的其餘部分就會變得有條理：先介紹資料結構本身，接著是 Redis 最常見的工作——快取模式，然後是基礎設施用途（佇列、鎖、速率限制），最後是如何在正式環境中穩定運行 Redis。

接下來，我們將具體介紹核心資料結構，從字串、雜湊、串列、集合與排序集合的概觀開始，並說明每種結構適合解決的實際問題。

重點摘要

  • Redis 是一個記憶體內資料結構儲存庫，因此其操作速度在亞毫秒級，這也是它被用在熱路徑上的原因。
  • 它不是簡單的鍵值儲存庫，而是提供真正的資料結構（字串、雜湊、串列、集合、排序集合等）以及對應的原子指令。
  • 強力使用情境：快取、工作階段、速率限制、佇列、即時功能，以及分散式協調。
  • Redis 輔助像 Postgres 這類主要資料庫，而不是作為關鍵資料的耐用、可查詢真實來源。
  • 當資料量超過記憶體容量、需要複雜查詢與聯結，或需要作為關鍵資料的正式記錄系統時，Redis 並不適合。

常見問題

Redis 到底是什麼？

Redis 是一個記憶體內資料結構儲存庫。它將資料保留在 RAM 中以提供亞毫秒級的存取，並提供字串、雜湊、串列、集合與排序集合等真正的資料結構，每種結構都有自己的原子指令，而不是單純的鍵值儲存庫。

Redis 只是快取嗎？

不是。快取雖然是最常見的用途，但 Redis 也支援速率限制、工作階段儲存、工作佇列、排行榜、發布/訂閱訊息，以及分散式鎖，因為這些功能都能對應到它內建的資料結構。

Redis 可以取代我的資料庫嗎？

對於關鍵資料來說，通常不行。Redis 優先考量速度，而非關聯式資料庫的耐用性與查詢能力，而且所有資料都放在記憶體中。你應該將它與像 Postgres 這類主要資料庫一起使用：Postgres 擁有耐用的真實資料來源，而 Redis 則加速熱路徑。

Redis 為什麼這麼快？

因為它將資料儲存在記憶體中，從 RAM 讀取的速度遠快於從磁碟讀取，因此操作能在遠低於一毫秒的時間內完成。此外，其資料結構也配備了高效且專為此設計的指令。

什麼時候不應該使用 Redis？

當你的資料集遠大於可用記憶體、需要複雜查詢、聯結或臨時報表，或是需要將它作為關鍵資料的耐用正式記錄系統時。這些工作應該交給磁碟型資料庫。

延伸閱讀

本文最初發表於 amanksingh.com/blog/redis-what-and-why。

關於作者

Aman Kumar Singh 是印度諾伊達的團隊主管與資深軟體工程師，撰寫關於全端工程、系統設計，以及使用 TypeScript、Next.js、NestJS、PostgreSQL 與 Redis 建置生產級 SaaS 的文章。