從 Redis 開始:用快取層為應用程式加速實戰指南

為什麼你的網站越來越慢?

想像一下,你開了一家便利商店,每位客人進門都要重新煮一杯咖啡、現烤一片吐司——就算賣的是同樣的東西,每次都從頭來過,隊伍很快就排到馬路上。傳統的「每次請求都去資料庫撈資料」就像這家店:熱門商品(首頁、熱門文章、使用者 session)被千萬次重複查詢,資料庫遲早被拖垮。

快取(Cache)就是店門口的「展示櫃」:把已經做好的咖啡先擺出來,客人來了直接拿,不用每次重煮。Redis 是目前最受歡迎的記憶體快取資料庫,它能把資料放在記憶體(RAM)裡,讀寫速度是硬碟資料庫的數十到數百倍。

一、Redis 是什麼?三分鐘建立心智模型

Redis(Remote Dictionary Server)是一個「鍵值(Key-Value)」型的記憶體資料庫。你可以把它想成一個超快的字典:給它一個 key,它瞬間回傳對應的 value。

  • 記憶體存取:資料放在 RAM,微秒級回應,遠快於 MySQL 的磁碟 I/O。
  • 豐富的資料結構:不只是字串,還有 Hash、List、Set、Sorted Set、甚至 Bitmap 與 Stream。
  • 可設定過期時間:每筆快取都能設 TTL(Time To Live),過期自動消失,避免「髒資料」。
  • 單執行緒模型:命令依序執行,天然避免並發競爭,程式邏輯好理解。

二、最常見的應用場景

  • 熱點資料快取:首頁文章列表、商品詳情、設定檔——這些讀多寫少,最適合放 Redis。
  • Session 共享:多台伺服器之間共享登入狀態,不再依賴本機檔案。
  • 排行榜 / 計數器:Sorted Set 天然支援分數排序,實時排行榜一行搞定。
  • 限流(Rate Limit):用 INCR + EXPIRE 輕鬆擋掉暴力請求。

三、實戰:用 PHP 接入 Redis 快取

以你熟悉的 PHP + MySQL 環境為例,我們在查資料庫前先問 Redis:「這筆資料你有嗎?」有就直接回傳,沒有再去資料庫撈、順手存進 Redis。

步驟 1:安裝並啟動 Redis(開發環境)。

# Ubuntu / Debian
sudo apt-get install redis-server
redis-server --daemonize yes
redis-cli ping   # 回傳 PONG 表示成功

步驟 2:PHP 安裝 PhpRedis 擴充(或改用 Predis 套件)。

# 使用 PECL 安裝原生擴充
pecl install redis
# 在 php.ini 加入
extension=redis.so

步驟 3:撰寫「先查快取、再查庫」的讀取邏輯。

<?php
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

function getHotPosts(PDO $pdo, Redis $redis, int $limit = 10): array {
    $key = "hot_posts:{$limit}";

    // 步驟 A:先問 Redis
    $cached = $redis->get($key);
    if ($cached !== false) {
        return json_decode($cached, true);   // 命中快取,直接回傳
    }

    // 步驟 B:快取未命中,才查 MySQL
    $stmt = $pdo->query("SELECT id, title FROM posts ORDER BY views DESC LIMIT {$limit}");
    $rows = $stmt->fetchAll(PDO::FETCH_ASSOC);

    // 步驟 C:寫回 Redis,設定 60 秒過期
    $redis->setex($key, 60, json_encode($rows));
    return $rows;
}

重點:「快取永遠可能過期或失效」,所以程式邏輯必須能在快取缺失時正確回退到資料庫,這才是一個健壯的設計。

四、三個新手最容易踩的坑

  • 快取穿透:查詢一個「根本不存在」的 key(如 id=-1),每次都打穿到資料庫。解法:對空結果也快取一個短暫的佔位值,或直接做參數校驗。
  • 快取雪崩:大量 key 同時過期,瞬間請求全湧向資料庫。解法:過期時間加上隨機抖動(如 60 ± 10 秒)。
  • 快取一致性:資料庫更新後,Redis 還是舊值。解法:寫入時同步刪除(或更新)對應快取,遵循「先更新 DB,再刪快取」。

五、什麼時候「不該」用快取

快取不是銀彈。資料強一致要求極高(如扣款餘額)、寫遠多於讀、或極少被重複查詢的資料,加快取反而增加複雜度與不一致風險。先量測瓶頸,再決定要不要加這一層。

互動話題:你在開發中遇過最棘手的效能瓶頸是什麼?是資料庫慢查、還是頻繁的遠端呼叫?歡迎在留言區分享,我們一起討論怎麼用快取優雅解決!