用 KV 在資料庫前面加一層快取

我們要在資料庫前面加一層快取。Worker 會先去問一個很快的鍵值資料庫（Workers KV）；只有在找不到值的時候，才去查比較慢的資料庫（D1），並把查到的答案存回 KV 供下次使用。這個做法叫做「cache-aside（旁路快取）」。

對於「讀多寫少」的資料——同一個商品頁、同一份設定、同一個個人檔案被讀取上千次——這個做法效益巨大：大多數請求根本不會打到資料庫，因此更快也更省錢。

三個角色一起合作。Worker 是負責決策的大腦；KV 是快速的快取；D1 則是「真相來源（source of truth）」，永遠保存正確、最新的資料。

對某個 key 的第一次請求是「未命中（miss）」：Worker 必須一路走到 D1 再走回來，然後把快取填好。之後的每一次請求（在 TTL 過期前）都是「命中（hit）」：直接從 KV 回傳，完全不碰 D1。

建立兩個儲存、綁定它們、塞一筆資料，然後寫 cache-aside 邏輯。前端只負責呼叫你的 API——它完全不知道背後有快取。

1. 建立 KV 命名空間與 D1 資料庫

   每個指令都會印出一組 id——下一步把它們貼進 wrangler.jsonc。

   bashcontent_copy複製

   npx wrangler kv namespace create CACHE
   npx wrangler d1 create shop

2. 把兩者綁定到 Worker

   這些綁定讓兩個儲存在程式碼裡能用 env.CACHE（KV）和 env.DB（D1）取用。

   jsoncontent_copy複製

   {
     "name": "cache-aside-api",
     "main": "src/index.js",
     "compatibility_date": "2025-01-01",
     "kv_namespaces": [
       { "binding": "CACHE", "id": "<your-kv-namespace-id>" }
     ],
     "d1_databases": [
       {
         "binding": "DB",
         "database_name": "shop",
         "database_id": "<your-d1-database-id>"
       }
     ]
   }

3. 建立資料表並塞一筆資料

   D1 是真相來源。執行一次這段 SQL，讓快取有東西可以載入。

   sqlcontent_copy複製

   CREATE TABLE IF NOT EXISTS products (
     id    INTEGER PRIMARY KEY,
     name  TEXT NOT NULL,
     price REAL NOT NULL
   );
   
   INSERT INTO products (id, name, price) VALUES
     (42, 'Mechanical Keyboard', 89.00);

4. 寫 cache-aside 讀取

   先用 get(key, "json") 問 KV。命中就立刻回傳；未命中就查 D1，再用 300 秒的 TTL 把結果 put 回 KV。

   jscontent_copy複製

   export default {
     async fetch(request, env) {
       const url = new URL(request.url);
       const id = url.pathname.split("/").pop();
       const key = `product:${id}`;
   
       // 1) Cache-aside: ask KV first
       let product = await env.CACHE.get(key, "json");
       if (product) {
         // HIT: return straight away, no database needed
         return Response.json({ source: "cache", product });
       }
   
       // 2) MISS: fall back to D1 (the source of truth)
       const { results } = await env.DB
         .prepare("SELECT * FROM products WHERE id = ?")
         .bind(id)
         .all();
       product = results[0] ?? null;
       if (!product) {
         return new Response("Not found", { status: 404 });
       }
   
       // 3) Re-fill the cache with a 5-minute TTL, then return
       await env.CACHE.put(key, JSON.stringify(product), {
         expirationTtl: 300,
       });
       return Response.json({ source: "database", product });
     },
   };

5. 寫入時讓快取失效

   當資料變動時，先更新 D1，再 delete(key)。快取副本就此消失，所以下一次讀取會未命中，並用最新資料重新填回快取。

   jscontent_copy複製

   // On any write, update D1 first, then invalidate the cached copy.
   async function updateProduct(env, id, data) {
     // 1) Write to the source of truth
     await env.DB
       .prepare("UPDATE products SET name = ?, price = ? WHERE id = ?")
       .bind(data.name, data.price, id)
       .run();
   
     // 2) Invalidate: delete the stale key so the next read repopulates it
     await env.CACHE.delete(`product:${id}`);
   }

6. 在前端呼叫它

   瀏覽器只是 fetch 你的 API。快取完全是伺服器端的事。

   jscontent_copy複製

   // Plain browser fetch - it never talks to KV or D1 directly.
   async function loadProduct(id) {
     const res = await fetch(`/api/product/${id}`);
     const data = await res.json();
     // data.source tells you whether it came from "cache" or "database"
     console.log("served from:", data.source);
     return data.product;
   }

• 依「能容忍多舊」來選 TTL：價格用秒、商品頁用分鐘、很少變的設定用小時。
• 寫入時務必失效（刪除 key），否則讀取者可能整段 TTL 都看到舊資料。
• 只快取真的常被讀取的東西——快取一次性的查詢只是白白浪費寫入次數。
• 絕不要把每位使用者的私密資料存在共用 key 下；把使用者 id 放進 key，例如 cart:{userId}。
• 盯著命中率看。命中率太低代表 TTL 太短，或 key 太細而無法被重複使用。
• 「未命中風暴」（冷門 key 同時湧入大量未命中）可能短暫衝擊 D1——讓資料庫查詢保持便宜並建好索引。