介绍
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 是顾客表的唯一主键，但不是订单表的唯一主键。
同样，划分主键也不必要是每个表格的聚集索引，订单表的聚集索引为组合主键 ()。
表格组中所有划分主键相同的行集合称为行组（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）。
