本次研討核心目標是圍繞崖山 DB、達夢 DB、GBASE三款國產數據庫，以及數據庫內核開發呂工程師的分享，深入了解共享集群 RAC 的開發技術。但實際效果未達預期，參會者多圍繞 “共享集群與分布式應用場景” 泛泛而談，缺乏深度技術拆解。

參會觀眾以 ORACLE ACE 為主，包括垃圾首席、狗屁總監等資深DB媒體角色，但其觀點普遍傾向 “共享集群優勢顯著、分布式存在缺陷”，存在明顯認知局限。需明確的是：RAC 已屬于日落架構，其并發能力上限固定；而分布式架構才是數據庫發展的核心趨勢（海鯊架構師觀點）。

需糾正一個常見誤區：分布式架構的選擇并非依賴數據量（如 “1TB 之內用 RAC” 的認知錯誤），且當前分布式數據庫雖存在短板（如兩階段事務提交導致的事務延遲），但仍具備不可替代的未來價值。

一、數據庫設計核心要求

數據庫設計需滿足以下 9 大目標，其中關鍵要求的具體定義如下：

1. 零丟失

2. 高穩定：指單機環境下，數據庫軟件可長時間運行，無自發崩潰現象

3. 高可用

4. 高并發：以 TPCC 指標為核心（每秒事務數、QPS、并發線程、并發連接用戶），重點衡量數據庫支持的用戶訪問量（即使前后端優化，最終落到 DB 端的 SQL 量不會減少）

5. 高性能：區分查詢性能與 UPDATE 性能，需注意 “性能” 與 “并發” 不可混為一談

6. 高便利：指數據庫易用性，包括配套工具豐富度、操作便捷性

7. 高觀測：支持多維度跟蹤手段，可清晰監控數據庫運行狀態、了解運行機制

8. 高安全

9. 高節能：該特性在大規模部署場景（如數據中心上萬臺 DB）中更明顯，例如某國產 DB 通過無鎖化編程，在無負載時 CPU 消耗可穩定維持在 15%

二、廣義與狹義分布式數據庫的定義

1. 廣義分布式數據庫

在外行人（含開發工程師、CTO、普通同事）認知中，只要數據庫依賴多臺物理 PC 服務器支撐，且單臺 / 多臺物理機 / 數據庫故障會導致業務部分 / 全部受影響，即可認定為分布式數據庫。

典型場景包括：

• 讀寫分離的主備 / 主從架構（屬于分布式中的 “克隆模式”）

• ORACLE RAC（存算分離的分布式：“算” 部分分布式部署，“存” 部分共享）

• MYSQL MGR（多主模式為分布式，單主模式非分布式；“算” 部分分布式，“存” 部分為克隆模式，非分片模式）

2. 狹義分布式數據庫

即 “分庫分表”，核心特征是 **“算” 與 “存” 雙維度拆分，且采用分片模式（非克隆模式）。

其核心價值是提升并發能力 **：通過水平擴展 PC 服務器實現彈性擴容，無需像 RAC 那樣依賴停機升級內存、CPU。

三、RAC 共享集群與分布式架構的核心差異

四、分布式與共享集群的選型建議

國企用戶普遍因 “RAC 穩定性經長期驗證” 而偏好該架構，但選型需結合并發量、活躍數據量、業務停機需求綜合判斷：

1. 優先選擇 RAC 的場景

• 對內業務：并發量可控，存在固定業務維修窗口

• 數據量與用戶增長有限： 新硬件支撐下，并發和數據量在RAC承接范圍內、共享存儲壓力可覆蓋當前IOPS需求，且未來用戶量、業務 SQL 功能增長也有限

• 核心優勢：短期內穩定性有保障，適合對 “擴展能力” 需求低的場景

2. 建議選擇分布式 DB 的場景

• 互聯網業務：并發量不可控，無業務停機維護窗口（需 7×24 小時在線）

• 業務增長特性：用戶量可能爆發式增長（如新業務快速起量），需支持在線橫向擴展

• 核心優勢：突破 RAC 擴展瓶頸，可通過增加 PC 服務器實現無感知擴容

五、當前狹義分布式數據庫的缺陷與優化思路

1. 現存缺陷

1. 事務性能：相對 RAC 存在明顯延遲

2. 分片設計：分片不合理易導致事務需跨多數據節點執行

3. 讀寫策略：未做針對性讀寫分離，查詢操作會消耗多數據節點的 IO 與 CPU

4. 數據完整性：無完整數據庫備份，若所有數據節點故障，部分業務會受影響

2. 優化建議：保留完整數據庫在線

核心方案：USER 表同時設計分片表與完整不分片表，完整數據庫的價值體現在：

1. 解決分片決策難題：無論采用何種分片算法，均存在 “部分 SQL 需跨節點更新” 的情況，完整數據庫可承接這類跨節點事務

2. 優化多節點讀操作：需跨多數據節點聯合執行的讀操作，可直接在完整數據庫中讀取，降低節點資源消耗

3. 事務與數據同步策略：

• 多數據節點事務：先在完整庫執行，再通過分片字段 BINLOG 復制到對應數據節點

• 單數據節點更新事務：通過 BINLOG 反饋并應用到主庫

最后狹義分布式數據庫架構設計，每個數據節點可以使用RAC共享集群架構來滿足高可用需求。當然較為經濟的MYSQL MGR也可以！