架構實戰營 - 模塊 4 作業

設計千萬級學生管理系統的考試試卷存儲方案

【作業要求】基於模塊 4 第 6 課的估算結果和 Redis sentinel 的初步方案設計，完善考試試卷存儲方案，具體包括：

1. 完善 Redis 的數據結構設計，明確具體使用哪種 Redis 數據結構

2. 設計具體的讀寫流程（可以文字描述也可以序列圖描述，序列圖要有文字輔助說明）

3. 對照模塊 4 第 6 課的性能估算結果，計算 Redis sentinel 集群的服務器數量和性能

數據結構

由於每門學科給學生的考試應該是一樣的，所以我們不幫每個學生存對應的試卷，而是用學科為單位儲存試卷以節省儲存空間，數據結構上可以使用 Set，具體格式如下：

Key: 學校 ID + 課程 ID + 考試 IDValue: 使用 JSON string，這樣只要 GET 一次即可把試卷的所有題目取回。JSON string 的格式如下：
[  {    ID: <題目 ID>,    Content: <題目內容>,    Type: <題目格式 - 判斷題｜選擇題｜大題>,    Options: [     {       ID: <選項 ID>,       Content: <選項內容>     }    ]  }]

讀寫流程

寫流程

由前端實作類似 Google 表單系統，老師可以新增問題，並幫每個問題選擇類別（Type），再撰寫題目內容，如果 Type 是選擇題，則需要給出選項，如果 Type 是判斷題，則由系統自動在 Options 裡新增是與否兩個選項，老師編輯完試卷後，由前端發送 JSON 格式的試卷給後端，後端會再將 JSON 轉為 JSON string 存入 MySQL，並以 SET 指令存入 Redis 作為緩存。

讀流程

讀取試卷時使用 GET 指令從 Redis 讀取試卷的 JSON string，後端取得 JSON string 後會轉成 JSON 格式回傳給前端，前端再依據不同題目的 Type 呈現給學生。

服務器數量與性能

1000 萬個學生同時考試，理論上 QPS 可達 1000 萬，不過設計上我們可以讓 1000 萬個學生分散在 1 分鐘內取得試卷即可，像是在後端到 Redis 之間設置 Rate Limit，所以理論上 Redis QPS 約為 17 萬。

由 Redis 官網的壓測數據可以發現 Redis 單純使用 SET 及 GET 的單機性能可達 5 ~ 10 萬 TPS，理論上我們只需要 4 台 Redis 即可應付，不過由於考試期間可能發現試卷錯誤需要臨時更改，所以我們需要額外的 Sentinel 機器來保證 Redis 集群的高可用性，這裡為了讓 Sentinel 能正確判斷 Master 節點的客觀下線，所以我們使用 3 台 Sentinel 機器，不過這 3 台 Sentinel 的規格可以不用跟 4 台 Redis 一樣，3 台 Sentinel 可以選擇 CPU 跟 Memory 小一點的機器。

最後我們要計算是否單個 Redis 集群即可存入所有數據，還是需要分片集群，所以我們假設每學期有 10 萬門課，每門課每週考試一次，所以當週需要緩存在 Redis 的試卷數據為 10 萬筆，假設每筆試卷大小為 1 KB，如此每週需要緩存的數據只有 100 MB，假設每門課一學期有 20 次考試，整個學期的考試數據都存入 Redis 也才 2GB，完全可以存入單個 Redis 集群。

所以我們最終需要 4 台 Redis 機器處理高 QPS，3 台 Sentinel 機器處理高可用。