雲上分散式SQL Server，你值得擁有

介紹
Microsoft SQL Azure 是微軟的雲關係型資料庫，後端存儲又稱為雲 SQL Server（Cloud SQL Server）。
它構建在 SQL Server 之上，通過分散式技術提升傳統關係型資料庫的可擴展性和容錯能力。

數據模型

（1）邏輯模型
雲 SQL Server 將數據劃分為多個分區，通過限制事務只能在一個分區執行來規避分散式事務。此外，它通過主備複製（Primary-Copy）協議將數據複製到多個副本，保證高可用性。
雲 SQL Server 中一個邏輯資料庫稱為一個表格組（table group），它既可以是有主鍵的，也可以是無主鍵的。
這裡只討論有主鍵的表格組。
如果一個表格組是有主鍵的，要求表格組中的所有表格都有一個相同的列，稱為劃分主鍵（partitioning key）。

雲 SQL Server 數據模型

圖中的表格組包含兩個表格，顧客表（Customers）和訂單表（Orders），劃分主鍵為顧客 ID（Customers 表中的 Id 列）。

劃分主鍵不需要是表格組中每個表格的共同唯一主鍵。圖中，顧客 ID 是顧客表的唯一主鍵，但不是訂單表的唯一主鍵。

同樣，劃分主鍵也不需要是每個表格的聚集索引，訂單表的聚集索引為組合主鍵 <顧客 ID，訂單 ID> (<Id, Oid>)。

表格組中所有劃分主鍵相同的行集合稱為行組（row group）。顧客表的第一行以及訂單表的前兩行的劃分主鍵均為 30，構成一個行組。

雲 SQL Server 只支持同一個行組內的事務，這就意味著，同一個行組的數據邏輯上會分佈到同一臺伺服器。

如果表格組是有主鍵的，雲 SQL Server 支持自動地水平拆分表格組裡的表格並分散到整個集群。同一個行組總是分佈在同一臺物理的 SQL Server 伺服器，從而避免了分散式事務。

這種的做法是避免了分散式事務的兩個問題：阻塞及性能。當然，也限制了用戶的使用模式。只讀事務可以跨多個行組，但事務隔離級別最多只支持讀已提交（read-committed）。


（2）物理模型
在物理層面，每個有主鍵的表格組根據劃分主鍵列有序地拆分成多個數據分區（partition）。這些分區之間互相不重疊，並且覆蓋了所有的劃分主鍵值。這就意味著每個行組屬於一個唯一的分區。
分區是雲 SQL Server 複製、遷移、負載均衡的基本單位。每個分區包含多個副本（預設為3），每個副本存儲在一臺物理的 SQL Server 上。
由於每個行組屬於一個分區，這也就意味著每個行組的數據量不能超過分區允許的存儲上限，也就是說單台 SQL Server 的容量上限。
一般來說，同一個交換機或者同一個機架的機器同時出現故障的概率較大，因而它們屬於同一個故障域（failure domain）。
雲 SQL Server 保證每個分區的多個副本分佈到不同的故障域。每個分區有一個副本為主副本（Primary），其他副本為備副本（Secondary）。
主副本處理所有的查詢，更新事務並以事務日誌的形式（類似資料庫鏡像的方式）將事務同步到備副本。各副本接收主副本發送的事務日誌並應用到本地資料庫。備副本支持讀操作，可以減輕主副本的壓力。


如圖所示，有四個邏輯分區 PA，PB，PC，PD，每個分區有一個主副本和兩個備副本。例如，PA 有一個主副本 PA_P 以及兩個備副本 PA_S1 和 PA_S2。

每台物理 SQL Server 資料庫混合存放了主副本和備副本。如果某台機器發生故障，它上面的分區能夠很快地分散到其他活著的機器上。
分區劃分是動態的，如果某個分區超過了允許的最大分區大小或者負載太高，這個分區將分裂為兩個分區。
假設分區 A 的主副本在機器 X，它的備副本在機器 Y 和 Z。如果分區 A 分裂為 A1 和 A2，每個副本都需要相應地分裂為兩段。
為了更好地進行負載均衡，每個副本分裂前後的角色可能不盡相同。例如，A1 的主副本仍然在機器 X，備副本在機器 Y 和機器 Z，而 A2 的主副本可能在機器 Y ，備副本在機器 X 和機器 Z。

架構
雲 SQL Server 分為四個主要部分：SQL Server 實例、全局分區管理器、協議網關、分散式基礎部件，如圖所示。

各個部分的功能如下：
每個 SQL Server 實例是一個運行著 SQL Server 的物理進程。每個物理資料庫包含多個子資料庫，它們之間互相隔離。子資料庫是一個分區，包含用戶的數據以及 schema 信息。
全局分區管理器（Global Partition Manager）維護分區映射表信息， 包括每個分區所屬的主鍵範圍， 每個副本所在的伺服器， 以及每個副本當前的狀態，狀態包括：副本當前是主還是備，前一次是主還是備，正在變成主，正在被拷貝，或者正在被追趕。
當伺服器發生故障時，分散式基礎部件檢測到後會將這些信息同步到全局分區管理器。全局分區管理器接著執行重新配置操作。另外，全局分區管理器監控集群中 SQL Server 的工作狀態，執行負載均衡、副本拷貝等管理操作。
協議網關（Protocol Gateway）負責將用戶的資料庫連接請求轉發到相應的主分區上。協議網關通過全局分區管理器獲取分區所在的 SQL Server 實例，後續的讀寫事務操作都會在網關與 SQL Server 實例之間進行。
分散式基礎部件（Distributed Fabric）用於維護機器上下線狀態，檢測伺服器故障併為集群中的各種角色執行選舉主節點操作。它在每台伺服器上都運行了一個守護進程。

複製與一致性
雲 SQL Server 採用 “Quorum Commit” 的複製協議，用戶數據存儲三副本，至少寫成功兩副本才可以返回客戶端成功。如圖所示，事務 T 的主副本分區生成事務日誌併發送到備副本。


如果事務 T 回滾，主副本會發送一個 ABORT 消息給備副本，備副本將刪除接收到的T事務包含的修改操作。如果事務 T 提交，主副本會發送 COMMIT 消息給備副本，並帶上事務提交順序號（Commit Sequence Number，CSN），

每個備副本會把事務 T 的修改操作應用到本地資料庫併發送 ACK 消息回覆主副本。如果主副本接收到一半以上節點的成功 ACK（包含主副本自身），它將在本地提交事務併成功返回客戶端。
某些備副本可能出現故障，恢復後將往主副本發送本地已經提交的最後一個事務的提交順序號CSN。如果兩者相差不多，主副本將直接發送操作日誌給備副本；如果兩者相差太多，主副本將首先把資料庫快照傳給備副本，再把快照之後的操作日誌傳給備副本。
主副本與備副本之間傳送邏輯操作日誌，而不是對磁碟物理頁的重做和回滾日誌。資料庫索引及 schema 相關操作（如創建、刪除表格）也通過事務日誌發送。
副本之間發送事務日誌/邏輯操作日誌保證各個副本的數據一致性是目前主流方案，包括TiDB, OceanBase也是採用同樣的方案。
實踐過程中發現了一些硬體問題，比如某些網卡會表現出錯誤的行為，因此對主備之間的所有消息都會做校驗（checksum）。
同樣，某些磁碟會出現“位翻轉”錯誤，因此，對寫入到磁碟的數據也做校驗（checksum）。

容錯
如果數據節點發生了故障，需要啟動宕機恢復過程。每個 SQL Server 實例最多服務 650 個邏輯分區，這些分區可能是主副本，也可能是備副本。
全局分區管理器統一調度，每次選擇一個分區執行重新配置（Reconfiguration）。
如果出現故障的分區是備副本，全局分區管理器首先選擇一臺負載較輕的伺服器，接著從相應的主副本分區拷貝數據來增加副本；

如果出現故障的分區是主副本，首先需要從其他副本中選擇一個最新的備副本作為新的主副本，接著選擇一臺負載較輕的機器增加備副本。
由於雲 SQL Server 採用 "Quorum Commit" 複製協議，如果每個分區有三個副本，至少保證兩個副本寫入成功，主副本出現故障後選擇最新的備副本可以保證不丟失數據。
全局分區管理器控制重新配置任務的優先順序，否則，用戶的服務會受到影響。比如某個數據分片的主副本出現故障，需要儘快從其他備副本中選擇最新的備副本切換為主副本；

某個數據分片只有一個主副本，需要優先複製出備副本。 另外，某些伺服器可能下線很短一段時間後重新上線，為了避免過多無用的數據拷貝，
這裡還需要配置一些策略，比如只有兩個副本的狀態持續較長一段時間（SQL Azure 預設配置為兩小時）才開始複製第三個副本。
全局分區管理器也採用 "Quorum Commit" 實現高可用性。它包含七個副本（奇數），同一時刻只有一個副本為主，分區相關的元數據操作至少需要在四個副本上成功。
如果全局分區管理器主副本出現故障，分散式基礎部件將負責從其他副本中選擇一個最新的副本作為新的主副本

負載均衡
負載均衡相關的操作包含兩種：副本遷移以及主備副本切換。新的伺服器節點加入時，系統內的分區會逐步地遷移到新節點，
這裡需要註意的是，為了避免過多的分區同時遷入新節點，全局分區管理器需要控制遷移的頻率，否則系統整體性能會下降。
另外，如果主副本所在伺服器負載過高，可以選擇負載較低的備副本升級為主副本來提供讀寫服務。這個過程稱為主備副本切換，不涉及數據拷貝。、
影響伺服器節點負載的因素包括：讀寫次數、磁碟/記憶體/CPU/IO 使用量等。全局分區管理器會根據這些因素計算每個分區及每個 SQL Server 實例的負載。

多租戶
雲存儲系統中多個用戶的操作相互干擾，因此需要限制每個 SQL Azure 邏輯實例使用的系統資源：

• 操作系統資源限制，比如 CPU、記憶體、寫入速度等等。如果超過限制，將在 10 秒內拒絕相應的用戶請求；
• SQL Azure 邏輯資料庫容量限制。每個邏輯資料庫都預先設置了最大的容量，超過限制時拒絕更新請求，但允許刪除操作；
• SQL Server 物理資料庫數據大小限制。超過該限制時返回客戶端系統錯誤。

總結
Microsoft SQL Azure 基於 SQL Server，通過分散式技術提升了資料庫的可擴展性和容錯能力。採用主備複製和分區機制，保證數據的高可用性和一致性。
系統通過全局分區管理、負載均衡和資源限制來優化性能並確保多租戶環境下的穩定運行。
SQL Server是目前比較主流並且有競爭力的產品，根據最新可靠消息，SQL Server 2025版本會內置SQL Azure 的分散式功能，再加上向量資料庫和AI功能，將會世界舞臺上具備更強大的競爭力。



參考文章
https://azure.microsoft.com/en-us/products/azure-sql/
https://link.springer.com/chapter/10.1007/978-1-4842-9225-9_2
https://www.sqlshack.com/azure-sql-database-connectivity-architecture/
https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/n-tier/multi-region-sql-server
https://subscription.packtpub.com/book/data/9781789538854/1/ch01lvl1sec08/azure-sql-database-architecture

加入我們的微信群，與我們一起探討資料庫技術，以及SQL Server、 MySQL、PostgreSQL、MongoDB 的相關話題。
微信群僅供學習交流使用，沒有任何廣告或商業活動。

本文版權歸作者所有，未經作者同意不得轉載。