近日，由IFClub社區主辦的《共享集群架構技術研討會》受到了廣泛關注。此次會議上，來自行業、產業及用戶方的眾多嘉賓分享了自己的觀點。本人作為主持人，深度參與了這一過程。共享集群架構過往沉寂過一段時間，隨著近兩年產品快速迭代、逐步成熟。這一架構形態產品，正受到更多的關注。相信未來在國產化大潮之下，必將成為關鍵核心場景的選擇之一。本文正是對此次會議的一點總結和展望。

1. 共享集群架構的前世今生

在互聯網時代之前，企業數據處理主要由大型機或小型機上的單實例數據庫（如Oracle、DB2）承擔。這些系統穩定但昂貴，且存在單點故障風險。隨著業務規模擴大，縱向擴展（Scale-up）的成本急劇攀升，可用性要求也日益苛刻。于是，共享磁盤架構（Shared-Disk） 的集群方案應運而生，其核心思想是多個計算節點共享同一份存儲。最具代表性的便是Oracle RAC（Real Application Clusters），誕生于20世紀末。在RAC架構中，多個數據庫實例同時掛載到一個共享存儲陣列（如SAN）上，通過高速互聯網絡（如Infiniband）和分布式鎖管理（DLM）機制，協調對各數據塊的并發訪問。這種架構實現了高可用性（故障節點可無縫切換）和有限的橫向擴展（主要擴展讀能力，寫沖突仍受限于全局鎖），但其復雜度較高，對存儲網絡性能存在依賴。

1)Oracle RAC 發展史

1.png

Oracle RAC發展歷程，可分為幾個階段：

? 發展前身階段：OPS

Oracle RAC的雛形始于Oracle 6和7時代的Oracle Parallel Server (OPS)。其核心采用共享磁盤架構，允許多個實例并行訪問同一數據庫，但依賴分布式鎖管理（DLM）協調并發訪問。OPS存在嚴重的鎖競爭和同步瓶頸。當不同實例需訪問同一數據塊時，需先將修改寫回磁盤，再由其他實例讀取，導致高延遲和擴展性受限。這一設計使其難以支撐高并發場景。

? 誕生與成熟階段：9i-11g

Oracle 9i正式推出Real Application Clusters (RAC)，其引入了Cache Fusion技術，通過私有網絡直接傳輸數據塊（而非經磁盤），極大減少I/O延遲；全局緩存服務（GCS）與全局鎖管理（GLM），解決OPS的一致性問題，提升高可用性。在10g版本，引入Automatic Storage Management (ASM)技術，統一管理共享存儲，替代裸設備，支持條帶化與鏡像優化；并內置了集群管理工具，不再依賴第三方軟件。后續在11g中則將Clusterware與ASM深度集成，所有文件（包括OCR和表決盤）均存于ASM磁盤組；并進行了大量優化，例如引入DRM技術減少跨節點傳輸，增加自動內存調優等。

? 租戶與AI革新：12c-19c

Oracle 12c中引入了多租戶的概念，支持容器數據庫（CDB）與可插拔數據庫（PDB），實現數據庫資源池化，降低運維成本。后續在18/19c中則引入了大量AI4DB的能力，如自動索引優化等。此外，還在應用連續性上取得重大進展，事務級故障透明恢復，實現“零感知”中斷。

? 云原生與智能化：19c+

在最近發展中，則將AI自動化與云環境深度整合成為新的發展熱點。

2)國產共享集群發展

國產數據庫的共享集群架構產品，相對發展較晚，但也經歷近二十年。此次研討會也邀請了幾家代表：達夢、南大通用、崖山、華為、易景。在會上大家也回顧了各自的研發歷史。其中達夢啟動最早，最早可追溯到09年啟動，早期通過在電網項目打磨，經歷十余年的研發完成。南大通用，最早的共享集群系統于2017年上線，距今也有近十年的歷史。崖山和華為，相對啟動較晚，但也都經歷了六年多的研發，并已成功發布并上線用戶核心系統。易景相對較晚，目前正在快速研發之中。從各家普遍反饋來看，共享集群架構產品研發難度極大、工程化考驗巨大，尤其是測試尤為重要。下面列舉幾家（DM、GBase、YashanDB）的技術架構

2.JPEG

3.PNG

4.png

2. 共享集群架構場景與選擇

1)共享集群典型場景

共享集群架構產品在過去相當長的一段時間，成為很多企業的基礎之選，那么用戶究竟是看重其什么能力呢？與幾位嘉賓老師研討后，總結出以下幾點：

? 高可用：讓故障切換做到真正“業務無感”

傳統主備架構面臨根本性局限：當主節點故障時，不僅需要數十秒甚至數分鐘的切換時間，還會導致正在進行的事務中斷、連接丟失和業務停滯。這種"斷崖式切換"對核心業務系統而言意味著直接的經濟損失和客戶體驗損傷。當然，隨著數據庫技術的不斷演進，包括跟很多客戶交流，當前的主備技術可以做到10秒以內的切換速度，在大部分業務場景下是可以接受的。但當面對最為核心的業務系統時，這一能力還是存在不足的。而共享集群架構實現了真正意義上的持續可用性。多個節點同時處于活躍狀態，共同承擔工作負載。當任一節點發生故障時，連接會自動、即時地遷移到健康節點，整個過程在秒級內完成，且保持事務連續性和連接穩定性。這種"平滑切換"能力使金融交易、電信計費、醫療系統等關鍵業務場景真正實現了"業務無感"的高可用保障，將計劃內和計劃外停機時間降至最低。

? 彈性擴展：實現存儲計算資源的“按需擴展”

傳統單一數據庫架構面臨Scale UP物理極限：當業務增長超出單機容量時，只能購買更昂貴的大型設備，既造成資源浪費，又無法應對突發流量沖擊。共享集群架構提供了一定程度的水平擴展的能力突破。計算層，用戶可以通過簡單增加節點的方式近線性擴展整體處理能力，且這一過程支持在線操作，無需停機即可實現容量擴充。存儲層，則可依賴于如集中或分布式存儲系統實現在線擴展。特別值得強調的是，智能負載管理技術能夠精準識別工作負載特征，通過自動化的負載隔離和資源分配策略，確保新增節點真正轉化為性能提升，而非簡單的資源堆砌。這種"按需生長"的彈性能力，使企業能夠從容應對促銷季、業務爆發期等場景，既避免資源浪費，又確保峰值性能。

? 資源池化：從資源孤島到全局統籌的效能革新

傳統架構中，為每個應用單獨部署數據庫實例導致大量"資源孤島"：不同系統的負載峰值時段不同，卻無法共享資源，造成總體資源利用率低下。共享集群架構通過多租戶資源池化技術實現了根本性變革。多個業務系統共享同一集群資源，但通過先進的隔離技術保證各自數據安全性和性能獨立性。創新的租戶級熱遷移技術則更進一步：當某個租戶需要更多資源時，可以在不中斷服務的情況下動態調整資源分配；當硬件需要維護時，可以將其上的租戶無縫遷移到其他節點，實現真正的"用戶無感"運維。這種資源統籌能力使整體資源利用率大幅提升，降低基礎設施投資。

? 降本增效：豐儉由人，讓用戶從容應對業務變化

共享集群架構的綜合價值最終體現在企業經營層面。類似Oracle RAC OneNode的輕量級部署選項，為中小企業提供了低成本的高可用解決方案，無需投資昂貴硬件即可獲得企業級可靠性。可以將其理解為以接近單實例的成本和復雜度，提供逼近 RAC 的高可用性。對于中小規模用戶、云服務平臺型用戶等，這一架構成為最優選。

2)共享集群 vs 分布式

經常會被問到這樣的問題，如何來選擇比較共享集群與分布式集群數據庫。其實從發展來看，共享集群發展歷史悠久，在很早以前已經承擔著用戶的關鍵核心業務系統；分布式集群出現較晚，早期是以互聯網類業務作為場景切入點的。在最近十多年，國產分布式數據庫憑借這一新技術架構實現彎道超車，在數據庫發展領域實現了階段性的跨越，一大批廠商及產品出現。在分布式技術上，又可細分為分庫分表類型和原生分布式類型等。那么如何對比選擇這兩類架構產品呢，這里引用我之前寫的文章中表格來說明

5.png

在這一表格中，對了單機、集中、分布式的幾種場景用法的使用差異。在此次研討會上，與會嘉賓也談到了集中式（共享集群）與分布式之爭。其核心觀點如下：

• 兩者差異在于處理數據復雜性的位置不同。分布式（特別是分庫分表）架構，是將復雜性置于應用層，通過應用來解決數據拆分后的處理難點，用戶在設計開發之初就不得不考慮因為引入分布式帶來的差異。而集中式則是將復雜性封閉在數據庫之內，從應用側角度來看，體驗無疑會更好。
• 分布式架構處理數據的本質，是在于對關系代數的拆分，SQL等價問題是難點，關系代數優化相對困難；其數據存儲位置是人為指定的，固對研發有一定侵入性。而集中式架構，更趨近于一種單機架構，功能閉合完整；其數據位置是自適應的，研發無感，要求低。
• 分布式架構在某一階段被多度吹捧，甚至很多用戶選擇是來自于輿論的結果。更為理性的做法是建立多維度的選型矩陣，根據實際業務場景來做選擇。
• 針對傳統企業，業務需求變化不大，穩態業務集中式更有優勢；而對于發展迅速、變化差異大、強調彈性伸縮能力的敏態業務，分布式更有優勢。
• 在選擇分布式架構時，成本是不得不去思考的問題，這里不僅是指因為選擇分布式而帶來的更多硬件資源的投入，還包括可能進而引發的來自應用側的改造、適配成本；來自運維側的管理、優化成本等等。總之，是要算一筆經濟賬。

3)“IOE”架構是否已過時

IOE（IBM小型機、Oracle數據庫、EMC存儲）架構作為企業級IT系統的經典方案，曾經長期承擔著金融、電信、能源等核心行業的關鍵業務負載。其穩定性、高可用性和強大的性能表現經過數十年實踐驗證，至今仍在許多對數據一致性和事務完整性要求極高的場景中發揮作用。然而，曾幾何時“去IOE”的呼聲日益高漲。這一趨勢的本質并非是對IOE技術架構本身的否定，而是源于對底層技術依賴國外廠商的擔憂。在數字化轉型和自主可控的戰略背景下，許多用戶希望減少對單一外部供應商的依賴，以降低供應鏈風險、增強技術自主權，并應對潛在的地緣政治影響。需要明確的是，“去IOE”最初是由互聯網企業提出的技術路線。互聯網業務通常具有高并發、彈性擴展、快速迭代的特性，分布式和開源方案更能滿足其成本控制和靈活演進的需求。但這一模式并不適用于所有行業。傳統核心業務系統往往需要強一致性、高可靠性和復雜的事務處理能力，而這些正是IOE架構的傳統優勢領域。隨著近些年，國產數據庫乃至其下游的主機、存儲的快速發展，基于國產的IOE架構方案已經逐步成熟，因此是否放棄這一架構應基于實際業務需求理性判斷。技術決策終究需回歸業務本質，盲從口號或過度保守均不可取。最終目標應是構建“架構可控”的能力，而非簡單粗暴的“拆除替換”。

3. 國產共享集群產品的發展之路

1)用戶廠商，雙向奔赴

國產共享集群架構數據庫產品正迎來歷史性發展機遇。然而，業界對其認知仍存在諸多誤區：或盲目推崇其替代潛力，或過度質疑其成熟度。理性看待國產共享集群產品，需基于歷史經驗、技術現實與工程規律，避免陷入非此即彼的極端判斷。

• 首先，需認識到技術成熟需要長期迭代的過程。 即便是Oracle RAC這類當今被視為標桿的共享集群架構，也經歷了漫長的發展周期。早期版本的Oracle RAC同樣面臨安裝復雜、穩定性不足、性能開銷大等問題：其安裝配置門檻極高，需專業顧問介入；資源爭用頻繁，跨節點訪問帶來的延遲顯著；故障難以定位，維護成本高昂。甚至因“對開發有感知”（如需人工指定節點親和性）而遭詬病。值得注意的是，國內許多用戶并未真正發揮RAC的多活價值，僅將其用作高可用熱備。因此，不能以Oracle RAC的現狀簡單對標國產產品的起步階段，而應客觀接受技術發展的客觀規律。
• 其次，國產數據庫需要真實的場景打磨與用戶信任。 共享集群架構的成熟離不開大規模核心場景的驗證。用戶應給予國產廠商更多機會，在可控環境中逐步推進試點，如從邊緣系統逐步延伸至核心業務。通過場景迭代暴露問題、優化架構，才是產品成熟的唯一路徑。封閉測試無法替代真實負載的復雜性，唯有開放合作才能加速技術淬煉。同時，國產廠商需主動汲取歷史經驗，規避已知陷阱。例如Cache Fusion的優化、全局鎖機制的精簡、腦裂防護的可靠性設計，國產廠商應深入研究這些經驗，避免重走彎路，尤其在底層工程實現上需重點突破：減少跨節點訪問的開銷、優化代碼執行路徑、降低對應用的侵入性。唯有如此，才能拿出真正合格的產品，而非僅停留在概念層面。
• 最后，必須正視共享集群產品的工程復雜性。 其難度并非來自技術理論的隱秘，而是工程實現的極致挑戰。從存儲層腦裂防護的可靠性，到故障自愈的自動化程度，再到多組件協同的穩定性，均需龐大的工程工作量支撐。建議采用組件化設計思路，將存儲管理、集群協調、計算引擎等模塊解耦，實現獨立測試與迭代，降低系統復雜度。此外，需構建覆蓋極端場景的測試體系，如網絡分區、節點瞬時負載激增等，才能確保產品在企業級場景中的可靠性。

2)未來發展，任重道遠

國產共享存儲數據庫集群正處于技術突破與生態構建的關鍵階段。在自主可控戰略驅動下，其發展需聚焦核心短板突破與場景化能力提升，方能真正承載關鍵行業負載。在技術上，一方面理性認清差距，快速補齊短板；另一方面基于新型硬件和理論突破，實現彎道超車。

• 針對前者提到的差距，要有著清醒的認識。一方面，包括高可用與容災體系仍需強化。當前故障切換時間與傳統RAC仍有差距，需從會話級容錯（如TAF）向事務級連續性（如TAC）演進，減少用戶感知中斷。在容災層面，除基礎主備架構外，應參考Oracle MAA 構建黃金級容災標準，支持跨地域切換與數據零丟失；另一方面需解決集中式架構下的鎖競爭與熱點瓶頸，通過智能條帶化（如ASM動態重平衡）、緩存親和性調度提升并發處理能力，尤其在銀行核心交易場景中驗證萬級TPS穩定性；第三實現包括HTAP混合負載能力、多租戶與管理能力等等。
• 針對后者提到的創新，硬件協同創新是重要突破口。隨著CXL互聯協議的成熟，內存池化與跨節點緩存共享成為可能，可顯著降低數據同步延遲，彌補集中式架構的性能短板。同時，RDMA網絡普及使節點間網絡延遲降至微秒級，為構建跨數據中心集群奠定基礎，但需優化協議棧以降低傳輸開銷。此外，如Paxos等共識協議在分布式領域的成功實踐，也是值得吸收消化的。未來國產共享集群需走“融合架構”之路：既吸收分布式架構的擴展性思路，又保留共享架構的數據一致性優勢，在開放硬件生態中構建差異化競爭力。唯有如此，方能在核心場景中真正替代傳統IOE架構。