云上分布式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 的相关话题。 微信群仅供学习交流使用，没有任何广告或商业活动.

  。

本文版权归作者所有，未经作者同意不得转载.

最后此篇关于云上分布式SQLServer，你值得拥有的文章就讲到这里了,如果你想了解更多关于云上分布式SQLServer，你值得拥有的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。