今天跟大家分享一個資料庫遇到瓶頸必須遷移的的案例。

過去朋友的公司用 Redis 來紀錄每件商品每分鐘的瀏覽數、庫存等資訊，以此來呈現即時的商品統計圖表（資料只要保存 1 個月）。

但隨著商品種類日漸增加（種類高達數萬），Redis 這類用記憶體（RAM）儲存資料的系統開始遇到了瓶頸。

過去還可以用課金增加記憶體的方式來解決，但最新的需求是將資料保存的時限拉長到一年（統計圖表時間搜尋範圍）。

而每天的資料量大約有 250MB，30 天還好說，變成 365 天成本就真的太可怕了。

於是團隊就開始討論合適的遷移方案。

方案一：Redis 僅保留 1 個月的資料量，過期的轉移到其他資料庫

最初的方案是增加一個排程腳本，每天定時將快過期的資料寫到其他資料庫保存。

之所以讓 Redis 保留一個月的資料量，因為系統默認顯示當前一個月的統計資料，存取次數較高。

但這麼做有許多缺點，比如：

• 如果使用者搜尋的時間點跨月，那後端的程式邏輯就會比較複雜。
• 需要同時維護兩套程式碼與資料庫，可能會造成未來隱憂（ex：版本升級、錯誤釐清）。
• 對團隊成員的技術水平有更高的要求，可能會提升招募的難度。

所以這個方案提出後當下就否決了。

方案二：將資料遷移到關連式資料庫

因為大部分的團隊成員都比較熟悉關聯式資料庫（ex: MySQL）。

所以大家想說要不就遷移到關聯式資料庫吧，這樣改版要花的時間成本較低。

但研究了一下發現可行性較低，因為：

• 如果不設計索引（index），搜尋效率會低到可怕。
• 但設計索引（index）後，因為每分鐘要寫入大量資料，所以會影響到寫入效能。
• 考量到未來統計報告可能需要更多資料，關聯式資料庫並不適合動態擴充欄位。

方案三：將資料遷移到非關連式資料庫（NoSQL）

幾經考慮後，最終的方案是選擇 MongoDB 這個 NoSQL。

主要原因是 MongoDB 無論在讀取、寫入，還是動態擴充欄位方面都能滿足需求。

在決定使用 MongoDB 後，接下來對資料結構做了一下調整。

在 Redis 中，原本將統計資料儲存在 Sorted Set 中，並使用 Hash 結構來存儲每個 timestamp 下的商品統計資料。結構如下：

Sorted Set: timestamps
Member: timestamp (e.g., 1620000000)
Hash: hash:timestamp (e.g., hash:1620000000) 
{
    "商品名稱1": "統計資料1",
    "商品名稱2": "統計資料2",
    ...
}

然而，這樣的設計有些問題。因為實際頁面通常只顯示最多 20 筆商品的統計資料；但為了達成這個目標，我們需要先抓取區間內的 timestamp，然後再找到對應的 Key（商品名稱）。

在 Redis 這麼做還 Ok，但如果轉換到 MongoDB，效率可能會不理想。

因此，在遷移到 MongoDB 時重新設計了資料結構，將商品作為 collection 的主要文件，timestamp 與統計資料作為內嵌文件。

新的 MongoDB 設計如下：

{
    "商品名稱": "商品名稱1",
    "統計資料": [
        {
            "timestamp": "1620000000",
            "data": "統計資料1"
        },
        {
            "timestamp": "16200000100",
            "data": "統計資料2"
        }
    ]
}

在這個設計中，我們將商品名稱設為 index，以提高查詢特定商品統計資料的效率。

小提醒：經過實驗後，這個資料結構並不是最理想的，詳情參考這篇文章（MongoDB 與 MySQL 建立 Index 對 Read/Write 的效能影響）

另外考量到時間搜尋範圍可能很大（ex: 4 個月的趨勢），面對大範圍的資料顯示，會以小時的統計資料呈現。

以上就是朋友跟我分享的資料庫遷移案例，希望對大家有幫助，如果有更好的方案，也歡迎留言分享。

如果你做的是電子商務系統，這個「痛點」會更為明顯，一但讓客戶等太久，公司就會流失大筆訂單。

為了解決這個問題，我們可以將資料設計成「快取」，這樣不但能大幅減少查詢資料的回傳時間（毫秒級別），還能有效降低後端資料庫的存取壓力。

本篇文章將以：「Node.js X Koa X Redis」作為範例解說；如果你完全沒接觸過 Redis，可以先參考這篇文章安裝環境。

應用場景說明

如果今天要設計一款「等公車」的服務，那你勢必要串接「第三方 API」來獲取即時訊息。

但有時第三方 API 的回傳時間並不理想，甚至有存取次數的限制；如果我們想降低第三方 API 存取次數，並減少使用者等待的回傳時間，我們可以針對資料做「快取（Cache）」設計。

等公車這個服務有幾個特點：

1. 「公車到站時間」對所有使用者來說都是一樣的。
2. 公車即將抵達的時間以「分鐘」來顯示，所以我們存取的第三方 API 的頻率不用太高。
3. 公車的線路非常多，但不會每條線路都有剛好使用者在查。

我們可以根據特點來設計資料更新的方案：

1. 我們並不需要輪詢所有的路線，因為很多資料我們就算取得，也沒有使用者會需要。
2. 因為即將抵達的時間以「分鐘」顯示，所以我們只要把更新的頻率設計在 1 分鐘以下即可（ex：5 秒鐘）。
3. 更新的策略可以採取「若 Redis 有資料就直接採用，若無則呼叫第三方 API 獲取資料」。

筆者之前有分享過用 Redis 解決「商品秒殺」的應用，有興趣的讀者可以參考這篇文章。

專案環境設置

這個小專案我們會使用到如下套件：

• koa：可以理解為 Express.js 的精簡版後端框架。
• @koa/router：路由器設定用的，看起來會比較直觀。
• ioredis：與 Redis 連線、溝通的套件。
• axios：HTTP 請求工具，我們透過它來 Call API。

使用如下指令便可「建立專案資料夾＆初始化專案＆安裝套件」：

mkdir redis-cache-example
cd redis-cache-example
npm init -y
npm install --save koa @koa/router ioredis axios

找個方便使用的第三方 API

本專案的主要目的，是讓大家理解如何將 API 回傳的資料快取。

所以這邊筆者選擇JSONPlaceholder的服務，他有提供虛擬的 RESTful API（重點是不用申請 Key 方便很多）。

上圖是 API 的回傳格式，大家可以看到，每個物件都有「id」的欄位，我們的程式會使用到這個參數來做 Demo（最多只有到 200，超過會回傳錯誤訊息）。

專案程式

本篇文章的目的是讓讀者理解 Redis 對效能有多大的提升，因此程式架構超級簡單，大概分成三個部分：

1. 將相關套件引入（koa、@koa/router、ioredis、axios）
2. Redis 資料庫連線
3. Get Method 的 RESTful API

而在 Get Method 存取 Redis 資料庫的邏輯為：

1. 先去 Redis 確認是否有快取，如果有就直接回傳。
2. 如果 Redis 沒資料，就要 Call API，並將第一次獲得的資料儲存到 Redis 裡面（資料過期時間設定為 5 秒鐘）。

為了方便讀者實作，筆者下面直接提供完整程式，你只要在專案資料夾下新增 index.js，然後複製貼上程式即可：

const Koa = require('koa');
const Router = require('@koa/router');
const Redis = require('ioredis');
const axios = require('axios')
const app = new Koa();
const router = new Router();

const redis = new Redis({
  host: '127.0.0.1',
  port: 6379,
  password: ''
});
redis.on("error", function (error) {
  console.error(error);
});

router.get('/todos/:id', async ctx => {
  try {
    const cacheTodos = await redis.get(`todos:${ctx.params.id}`);
    if (cacheTodos) {
      console.log("從 Redis 獲得資料");
      ctx.body = JSON.parse(cacheTodos);
      return;
    }

    // 呼叫 API
    const response = await axios.get(`https://jsonplaceholder.typicode.com/todos/${ctx.params.id}`);
    console.log("將第一次獲得的資料儲存到 Redis");
    // 把 API 回傳結果放入 Redis，並設定 5 秒的過期時間（Expire Time）
    await redis.set(`todos:${ctx.params.id}`, JSON.stringify(response.data), "EX", 5);

    ctx.body = response.data;
  } catch (err) {
    ctx.body = err;
  }
});

app.use(router.routes());
app.listen(3000);

原始碼：redis-cache.js（GitHub Gist）

測試程式，確認結果是否符合預期

STEP 1：先在終端機輸入 redis-server，啟動 Redis Server。

STEP 2：輸入 node index.js 運行專案。

STEP 3：打開 POSTMAN，實際體驗有了 Redis Cache API 的資料後，減少了多少回傳時間。

如果想感受差異，可以看看下面筆者錄製的 Gif，裡面也有呈現過 5 秒就要重新抓取資料的邏輯。

結語

本篇文章的重點在於「Cache 的思路」，Redis 只是協助我們達成目標的工具，即使改用 Memcached 也能達到相同目的。

希望這個簡單的範例讓大家對 Redis 的應用有更近一步的認識，也歡迎大家留言分享自己的應用喔！

不過面對這個情境，Redis 表示終於輪到我了！今天這篇文章會以 Node.js + Redis 為範例，帶讀者一起解決這個問題。

大綱

1. 如何解決高併發情境的商品秒殺問題
   • 1.1 面試官為什麼會問？
   • 1.2 面試官想從答案確認什麼？
   • 1.3 筆者提供的簡答
2. 回答問題所需具備的知識
   • 2.1 先了解 Redis 的基礎知識
   • 2.2 使用 Node.js + Redis 解決高併發秒殺問題
   • 2.3 模擬秒殺情境確認商品沒有超賣
3. 衍伸問題
   • 3.1 如果有數萬用戶同時查看 TOP100 的點數排行榜，資料庫如何設計？
   • 3.2 Redis 跟 Memcached 的差異

1. 如何解決高併發商品秒殺問題

1.1 面試官為什麼會問？

這算是資料庫的常見面試題，除了金融、電商喜歡考這題外；社交平台、新創公司、遊戲產業也會換個形式考類似的題目。

因為這算是職缺所需具備的技術，如果求職者沒有相關經驗可能就會止步於這個關卡。

如果有去以上產業的打算，最好有一定的 NoSQL（ex：Redis、MongoDB） 基礎再去面試；因為在面試官的眼中有基礎跟完全不會的差距很大，求職者可以沒有實務經驗，但明知產業會碰到這些技術還不去學習就是態度問題了。

1.2 面試官想從答案確認什麼？

• 能提出高併發情境商品秒殺的解決方案
• 如果解決方案為 NoSQL，對它的認知有多少
• 是否接觸過同類型的 NoSQL

1.3 筆者提供的簡答

通常這類型的秒殺活動都有固定檔期，我會先將活動用的商品及庫存數量同步到 Redis 資料庫；為了避免超賣，在 Client 端下單時會執行 Lua 腳本，當秒殺到指定數量或是時間結束後就不再接受請求，活動結束後將 Redis 的資料同步到關聯式資料庫。

2. 回答問題所需具備的知識

2.1 先了解 Redis 的基礎知識

如果有短時間大量訪問、需要性能提升的需求，往往會先想到 Redis 這個記憶體資料庫。

• Redis 為什麼快？

  • 記憶體資料庫
    記憶體讀寫本來就快。

  • 單執行緒（single-threaded）
    如果使用多執行緒會耗費時間在上下文的切換以及加鎖上面；而單執行緒會依照請求順序執行，不需考慮同步以及加鎖帶來的效能問題。
    Redis 是基於記憶體操作，所以效能的瓶頸不在 CPU 而在記憶體、網路頻寬；因為 CPU 不是瓶頸，所以可以開多個 Redis 建立 Cluster 分散壓力。

  • I/O 多路複用（multiplexing）
    Redis 使用了 epoll IO 多路複用，可以用一條執行緒處理併發的網路請求。

    這個有點抽象，我用繳交作業為情境說明：
    假設你是一個老師，採用多路復用的原則批改作業，那你批改的順序就是看誰先繳交作業，而不是按照學號順序批改（此作法中間有人沒交作業就會卡住）；這樣就能避免大量無用操作，為非阻塞模式的實現。

• Redis 資料保存方案
  可以使用 RDB 、AOF 來做持久化。

  • RDB 持久化（Redis Database）
    在指定的時間間隔內將資料 dump 到硬碟；因為是定期操作，如果 Redis 當機會遺失部分資料，此方案適合大規模資料恢復。
  • AOF 持久化（Append Only File）
    這個方案可以完整紀錄所有資料的變化，因為採用日誌追加的方式，所以就算當機也不會影響已經儲存的日誌，災難復原的完成度高；缺點是檔案比 RDB 大、大規模資料恢復速度較 RDB 慢。

• Redis 資料淘汰機制
  Redis 主要保存的都是熱點資訊，在儲存資料有限的狀態下（記憶體不足，無法寫入新資料）；就要合理的設定淘汰機制：

  • 選擇性移除有設定過期時間的資料
    • volatile-lru：挑選最近較少使用的資料淘汰。
    • volatile-ttl：挑選即將過期的資料淘汰。
    • volatile-random：挑選隨機資料淘汰。
  • allkeys-lru：挑選最近較少使用的資料淘汰。
  • allkeys-random：挑選隨機資料淘汰。
  • no-enviction：禁止淘汰；若選用這個設定，當數據到達 maxmemory 時會回傳 OOM 錯誤。

  原則上淘汰策略以「volatile-lru、allkeys-lru」為主（淘汰較少使用的資料）。

2.2 使用 Node.js + Redis 解決高併發秒殺問題

• 目標
  • 產生秒殺商品基礎資訊（商品名稱、庫存）
  • 模擬秒殺情境，確認是否會超賣
  • 確認有保存購買人資訊
• 使用技術

  • Redis
    本篇文章使用 Redis 的 Hash、List type 來儲存資訊。

    如果完全沒有相關基礎，建議先參考這篇文章來安裝 Redis 以及它的 GUI 工具。

  • Lua 腳本
    為了避免超賣，這裡採用 Lua 腳本；在 Redis Server 執行 EVAL 指令時，在結果回傳前只會執行當下 Lua 腳本的邏輯，其他 Client 端的命令須等待直到 EVAL 執行完為止。

    Lua 腳本的邏輯應盡量簡單以保證執行效率，否則會影響 Client 端的體驗。

• 程式架構

  • 主程式：redisSecKill.js

    • 先啟用 Redis Client 端（如未安裝相關套件，請在專案資料夾下輸入 yarn add ioredis）。
    • 用 prepare 函式，以 Hash type 建立參加秒殺的產品庫存。
    • 用 secKill 函式模擬使用者購買行為，緩存並執行 Lua 腳本。

    const fs = require("fs");
    const Redis = require("ioredis");
    const redis = new Redis({
      host: "127.0.0.1",
      port: 6379,
      password: "",
    });
    
    redis.on("error", function (error) {
      console.error(error);
    });
    
    async function prepare(item_name) {
      // 參加秒殺活動的商品庫存
      await redis.hmset(item_name, "Total", 100, "Booked", 0);
    }
    
    const secKillScript = fs.readFileSync("./secKill.lua");
    
    async function secKill(item_name, user_name) {
      // 1. 緩存腳本取得 sha1 值
      const sha1 = await redis.script("load", secKillScript);
      // console.log(sha1);
    
      // 2. 透過 evalsha 執行腳本
      // redis Evalsha 命令基本語法如下
      // EVALSHA sha1 numkeys key [key ...] arg [arg ...]
      redis.evalsha(sha1, 1, item_name, 1, "order_list", user_name);
    }
    
    function main() {
      console.time("secKill");
      const item_name = "item_name";
      prepare(item_name);
      for (var i = 1; i < 10000; i++) {
        const user_name = "baobao" + i;
        secKill(item_name, user_name);
      }
      console.timeEnd("secKill");
    }
    main();
    

  • Lua 腳本：secKill.lua
    在 Lua 腳本執行邏輯：「確認下單數量」➜「取得商品庫存」➜「如果庫存足夠就下單」➜「儲存購買者資訊（List type）」。

    local item_name = KEYS[1]
    local n = tonumber(ARGV[1])
    local order_list = ARGV[2]
    local user_name = ARGV[3]
    if not n  or n == 0 then
      return 0
    end
    local vals = redis.call("HMGET", item_name, "Total", "Booked");
    local total = tonumber(vals[1])
    local booked = tonumber(vals[2])
    if not total or not booked then
      return 0
    end
    if booked + n <= total then
      redis.call("HINCRBY", item_name, "Booked", n)
      redis.call("LPUSH", order_list, user_name)
      return n
    end
    return 0
    

2.3 模擬秒殺情境確認商品沒有超賣

• SETP 1：在專案資料夾下輸入 node redisSecKill.js 模擬秒殺

  

• SETP 2：待執行完後，用 Redis GUI 程式確認商品沒有超賣

  

• SETP 3：確認訂單都有對應的買家

  

補充

文章程式只是 MVP，現實狀況還有很多要設計的：

• 哪些商品被列為秒殺，如何紀錄。
• 設定秒殺開始、結束時間。
• 如何將 Redis 資料存入關聯式資料庫中。

3. 衍伸問題

3.1 如果有數萬用戶同時查看 TOP100 的點數排行榜，資料庫如何設計？

考點：對 Redis Zset 這個資料型態的認知與應用

我會使用 Redis 這個記憶體資料庫，建立一個有序集合（Zset）來儲存用戶的資訊。

在設計上，用戶（member）是唯一值，且每個用戶都會關聯一個點數（score），這樣用戶就可以按照分數來排序。

功能實現上會透過 zrevrange Leaderboard 0 99 withscores 這段指令來顯示 TOP100 的點數排行榜。

• zrevrange：依照點數（score）檢視排行榜
• Leaderboard：排行榜名稱（可以自行定義）
• 0 99：TOP100 的意思
• withscores：連點數（score）一起顯示

3.2 Redis 跟 Memcached 的差異

考點：是否了解過同類型的技術以及差異

• Memcached 只支援簡單的資料型態，而 Redis 支援多種資料型態（String、Hash、List、Set、Zset、Stream）。
• Memcached 不支援資料持久化，而 Redis 提供 RDB 跟 AOF 兩種方案。

同樣身為記憶體資料庫，Memcached 提供簡單的使用方式，而 Redis 提供豐富的功能。

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

參考資源

1. 手把手帶你在 MacOS 安裝 Redis ＆Another Redis Desktop Manager(筆者部落格)
2. 用 Node.js + Redis 解決高併發秒殺問題(筆者部落格)
3. redis 之 sorted sets 類型及操作
4. 使用 redis 的有序集合實現排行榜功能

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571

大綱
一、文章目標
二、使用技術
  ➤ Redis
  ➤ Lua
三、程式架構
  ➤ 主程式：redisSecKill.js
  ➤ Lua腳本：secKill.lua
四、執行結果
五、補充

一、文章目標

1. 產生秒殺商品基礎資訊(商品名稱、庫存)
2. 模擬秒殺情境，確認是否會超賣
3. 確認有保存購買人資訊

二、使用技術

Redis

1. 如果完全沒有相關基礎，建議先參考這篇文章來安裝 Redis 以及他的 GUI 工具
2. 本篇文章使用 Redis 的 Hash、List type 來儲存資訊

Lua

1. 為了避免超賣，這裡採用 Lua 腳本
2. 在 Redis Server 執行 EVAL 指令時，在結果回傳前只會執行當下 Lua 腳本的邏輯，其他 Client 端的命令須等待直到 EVAL 執行完為止。

Lua 腳本的邏輯應盡量簡單以保證執行效率，否則會影響 Client 端的體驗

三、程式架構

主程式：redisSecKill.js

1. 先啟用 Redis Client 端（如未安裝相關套件，請在專案資料夾下輸入 yarn add ioredis）
2. 用 prepare 函式，以 Hash type 建立參加秒殺的產品庫存
3. 用 secKill 函式模擬使用者購買行為，緩存並執行 Lua 腳本

const fs = require('fs');
const Redis = require('ioredis');
const redis = new Redis({
    host: '127.0.0.1',
    port: 6379,
    password: ''
});

redis.on("error", function (error) {
    console.error(error);
});

async function prepare (item_name) {
    // 參加秒殺活動的商品庫存
    await redis.hmset(item_name, "Total", 100, "Booked", 0);
}

const secKillScript = fs.readFileSync('./secKill.lua');

async function secKill (item_name, user_name) {
    // 1. 緩存腳本取得 sha1 值
    const sha1 = await redis.script("load", secKillScript);
    // console.log(sha1);

    // 2. 透過 evalsha 執行腳本
    // redis Evalsha 命令基本語法如下
    // EVALSHA sha1 numkeys key [key ...] arg [arg ...] 
    redis.evalsha(sha1, 1, item_name, 1, "order_list", user_name);
}

async function main () {
    console.time('secKill')
    const item_name = "item_name"
    prepare(item_name)
    for (var i = 1; i < 10000; i++) {
        const user_name = "baobao" + i
        secKill(item_name, user_name)
    }
    console.timeEnd('secKill')
}
main()

原始碼：redisSecKill.js（GitHub Gist）

Lua 腳本：secKill.lua

在 Lua 腳本執行「取得商品庫存」➜「如果庫存足夠就-1」➜「儲存購買者資訊(List type)」

local n = tonumber(ARGV[1])
local order_name = ARGV[2]
if not n  or n == 0 then
    return 0       
end                
local vals = redis.call("HMGET", KEYS[1], "Total", "Booked");
local total = tonumber(vals[1])
local blocked = tonumber(vals[2])
if not total or not blocked then
    return 0       
end                
if blocked + n <= total then
    redis.call("HINCRBY", KEYS[1], "Booked", n)
    redis.call("LPUSH", order_name,ARGV[3])                                   
    return n;   
end                
return 0

原始碼：secKill.lua（GitHub Gist）

四、執行結果

SETP 1：在專案資料夾下輸入 node redisSecKill.js 模擬秒殺

SETP 2：待執行完後，用 Redis GUI 程式確認商品沒有超賣

SETP 3：確認訂單都有對應的買家

五、補充

上面程式只是 MVP，現實狀況還有很多要討論的：

1. 哪些商品被列為秒殺，如何紀錄
2. 設定秒殺開始時間、結束時間
3. 存在 Redis 的資料怎麼存入關連式資料庫中

如果你對 Redis 感興趣，筆者這邊也整理了很多相關資源：
1. 一文讓你徹底瞭解 Redis(進階)，史上最全,不看後悔！！！【建議收藏】
2. 【总结】瞬时高并发（秒杀/活动）Redis 方案
3. redis 之 sorted sets 类型及操作
4. node.js 中对 redis 的安装和基本操作
5. Node.js 中实践 Redis Lua 脚本
6. 使用 Redis 搭建电商秒杀系统

筆者也是剛學習 Redis 的新人，如果描述有誤，或是有更好的解決方式，再麻煩大神們不吝賜教，感謝～

一、安裝並啟動 Redis

SETP 1：打開終端機輸入下面指令安裝 Homebrew（若安裝過請忽略）

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

SETP 2：使用 Homebrew 安裝 Redis

brew install redis

SETP 3：啟動 Redis

啟動 Server 終端機執行指令 redis-server

開一個 Terminal 啟動 Client 終端機執行指令 redis-cli （如果沒開新的 Terminal 直接做是不行的喔！）

SETP 3：測試 Redis 基礎功能

ping
set foo bar
get foo

如果操作結果跟上圖一樣就恭喜你安裝成功嚕～

二、安裝及使用 Another Redis Desktop Manager

SETP 1：使用 Homebrew 安裝

brew install --cask another-redis-desktop-manager

SETP 2：安裝後可以在應用程式列表看到他，但如果你的作業系統是 MacOS 10.15 以上，打開程式時會遇到如下錯誤

SETP 3：看到錯誤別慌張，打開「系統偏好設定」，選擇「安全性與隱私權」

SETP 4：在「一般」的分頁下，「強制打開」這個 APP

SETP 5：在系統的警告下，鼓氣勇氣「打開」他吧！

SETP 6：打開後迎面而來的是簡潔有力的畫面，點擊左上角「New Connection」建立新連線

SETP 7：直接使用默認的設定即可，按下「OK」

SETP 8：最後進入 DB 確認剛剛建立的 key-value(foo-bar) 是否存在

如果 redis 沒有選擇 DB，預設都是 0

大功告成嚕！恭喜大家踏出學習 Redis 的第一步～

參考資源：

1. macOS 上安裝 Redis
2. Another Redis Desktop Manager