Discuz!NT 千萬級資料架構演進：Tokyo Cabinet 與 MongoDB 的雙引擎策略

面對論壇核心資料表 (主題、用戶) 突破千萬筆的挑戰，Discuz!NT 企業版採用「關係型資料庫 + NoSQL 雙引擎」架構：MSSQL 維持交易一致性與複雜查詢，Tokyo Cabinet (Tokyo Tyrant) 與 MongoDB 分別承擔高併發讀取與彈性文件儲存。本文深度剖析選型邏輯、介面設計、部署考量與風險控管策略。

千萬級資料表的痛點

• 分表分庫：依 UID 範圍水平切分，但跨表 JOIN (如主題左連用戶) 需應用層組裝，存儲程序複雜度暴增。
• 資料冗餘：主題表冗餘用戶欄位，寫入放大、一致性難保證、儲存成本上升。
• 單表效能瓶頸：索引膨脹、鎖爭用、備份還原耗時，傳統關係型資料庫單機難以支撐高併發讀寫。

為何選擇 Tokyo Cabinet + MongoDB 雙引擎

統一介面設計：可換裝的 NoSQL 抽象層

public interface INoSqlProvider
{
    // 基礎 CRUD
    bool Set(string key, byte[] value, TimeSpan? expiry = null);
    byte[] Get(string key);
    bool Remove(string key);
    bool Exists(string key);

    // 批次操作
    Dictionary GetMultiple(IEnumerable keys);
    void SetMultiple(IDictionary items, TimeSpan? expiry = null);

    // 進階 (視實作而定)
    long Increment(string key, long delta);
    IEnumerable Keys(string pattern);
}

實作類別：TokyoTyrantProvider、MongoDbProvider，透過 DI 容器註冊，配置檔切換：

<add key="NoSqlProvider" value="TokyoTyrant" /> <!-- 或 MongoDB -->

實際應用場景

1. 用戶 Session 儲存：Tokyo Tyrant 取代 ASP.NET SQL Session State，單機 10 萬 QPS+，重啟不丟失。
2. 主題/貼文瀏覽計數：原子增量 Increment，避免資料庫熱點行鎖。
3. 熱門標籤、最新動態：MongoDB 彈性文件儲存，支援陣列、巢狀物件，查詢靈活。
4. 搜尋建議、自動完成：Tokyo Cabinet B+Tree 索引支援前綴掃描。

風險控管與「考核期」機制

• ✅ **非核心路徑先行**：優先用於輔助功能 (快取、計數、日誌)，核心交易 (發文、交易) 仍走 MSSQL。
• ✅ **雙寫驗證**：上線初期同步寫入 MSSQL 與 NoSQL，離線比對資料一致性。
• ✅ **故障降級**：NoSQL 不可用時自動回退 MSSQL 或本地快取，不影響主流程。
• ✅ **監控儀表板**：延遲、錯誤率、命中率、記憶體/磁碟用量實時告警。
• ✅ **考核期 3-6 個月**：通過穩定性、效能、運維驗證後，才考慮擴展至核心業務。

部署架構圖

結語

Discuz!NT 的雙引擎策略展示了「關係型做交易、NoSQL 做高併發讀寫與彈性資料」的務實架構哲學。統一介面、漸進遷移、嚴格考核，讓技術創新在可控風險下落地。對於面臨相似規模挑戰的團隊，此案例極具參考價值。