SQL Azure简介

SQL Azure是Azure存储平台的逻辑数据库，物理数据库仍然是SQL Server。一个物理的SQL Server被分成多个逻辑分片(partition)，每一个分片成为一个SQL Azure实例，在分布式系统中也经常被称作子表(tablet)。和大多数分布式存储系统一样，SQL Azure的数据存储三个副本，同一个时刻一个副本为Primary，提供读写服务，其它副本为Secondary，可以提供最终一致性的读服务。每一个SQL Azure实例的允许的最大数据量可以为1GB或者5GB(Web Edition)，10GB, 20GB, 30GB, 40GB或者50GB(Business Edition)。由于限制了子表最大数据量，Azure存储平台内部不支持子表分裂。

如上图，与大多数Web系统架构类似，Azure存储平台大致可以分为四层，从上到下分别为：

• Client Layer：将用户的请求转化为Azure内部的TDS格式流；
• Services Layer：相当于网关，相当于普通Web系统的逻辑层；
• Platform Layer：存储节点集群，相当于普通Web系统的数据库层；

Services Layer

服务层相当于普通Web系统的逻辑层，包含的功能包括：路由，计费，权限验证，另外，SQL Azure的服务层还监控Platform Layer中的存储节点，完成宕机检测和恢复，负载均衡等总控工作。Services Layer的架构如下：

如上图，服务层包含四种类型的组件：

1, Front-end cluster：完成路由功能并包含防攻击模块，相当于Web架构中的Web服务器，如Apache或者Nginx；

2, Utility Layer：请求服务器合法性验证，计费等功能；

3, Service Platform：监控存储节点集群的机器健康状况，完成宕机检测和恢复，负载均衡等功能；

4, Master Cluster：配置服务器，保存每个SQL Azure实例的副本所在的物理存储节点信息；

其中，Master Cluster一般配置为七台机器，采用”Quorum Commit”技术，也就是任何一个Master操作必须同步到四个以上副本才算成功，四个以下Master机器故障不影响服务；其它类型的机器都是无状态的，且机器之间同构。上图中，请求的流程说明如下：

1, 客户端与Front-end机器建立连接，Front-end验证是否支持客户端的操作，如CREATE DATABASE这样的操作只能通过Azure实用工具执行；

2, Front-end网关机器与客户端进行SSL协议握手认证，如果客户端拒绝使用SSL协议则断开连接。这个过程中还将执行防攻击保护，比如拒绝某个或某一段范围IP地址频繁访问；

3, Front-end网关机器请求Utility Layer进行必要的验证，如请求服务器地址白名单认证；

4, Front-end网关机器请求Master获取用户请求的数据分片所在的物理存储节点副本信息；

5, Front-end网关机器请求请求Platform Layer中的物理存储节点验证用户的数据库权限；

6, 如果以上认证均通过，客户端和Platform Layer中的存储节点建立新的连接；

7~8, 后续所有的客户端请求都直接发送到Platform Layer中的物理存储节点，Front-end网关只是转发请求和回复数据，起一个中间代理作用。

Platform Layer

平台层就是存储节点集群，运行物理的SQL Server服务器。客户端的请求通过Front-end网关节点转发到平台层的数据节点，每个SQL Azure实例是SQL Server的一个数据分片，每个数据分片在不同的SQL Server数据节点上存储三个副本，同一时刻只有一个副本为Primary，其它副本为Secondary。数据写入采用”Quorum Commit”策略，至少两个副本写成功时才返回客户端，这样即使一个数据节点发生故障也不影响正常服务。Platform Layer的架构如下：

vcm0uanBn" height="412" src="http://www.cppentry.com/upload_files/article/57/1_czsxi__.jpg" width="550" />

如上图，每个SQL Server数据节点最多服务650个数据分片，每一个数据节点上的所有数据分片的写操作记录到一个操作日志文件中，从而提高写入操作的聚合性能。每个分片的多个副本之间的数据同步是通过同步并回放操作日志实现的，由于每个分片的副本所在的机器可能不同，因此，每个SQL Server存储节点最多需要和650个其它存储节点进行数据同步，网络聚合不够，这也是限制单个存储节点最多服务650个分片的原因。

如上图，每个物理存储节点上都运行了一些实用的deamon程序（称为fabric），大致介绍如下：

1, Failure detection：检测数据节点故障从而触发Reconfiguration过程；

2, Reconfiguration Agent：节点故障后负责在数据节点重新生成Primary或者Secondary数据分片；

3, PM (Partition Manager) Location Resolution：解析Master的地址从而发送数据节点的消息给Master的Partition Manager处理；

4, Engine Throttling：限制每个逻辑的SQL Azure实例占用的资源比例，防止超出容量限制；

5, Ring Topology：所有的数据节点构成一个环，从而每个节点有两个邻居节点可以检测节点是否宕机；

分布式相关问题

1, 数据复制(Replication)

SQL Azure中采用”Quorum Commit”的策略，普通的数据存储三个副本，至少写成功两个副本才可以返回成功；Master存储七个副本，至少需要写成功四个副本。每个SQL Server节点的更新操作写到一个操作日志文件中并通过网络发送到另外两个副本，由于不同数据分片的副本所在的SQL Server机器可能不同，一个存储节点的操作日志最多需要和650个分片数量的机器通信，日志同步的网络聚合效果不够好。Yahoo的PNUTS为了解决这个问题采用了消息中间件进行操作日志分发，达到聚合操作日志的效果。

2, 宕机检测和恢复

SQL Azure的宕机检测论文中讲的不够细，大致的意思是：每个数据节点都被一些对等的数据节点监控，发现宕机则报告总控节点进行宕机恢复过程；同时，如果无法确定数据节点是否宕机，比如待监控数据节点假死而停止回复命令，此时需要由仲裁者节点进行仲裁。判断机器是否宕机需要一些协议控制，后面的文章会专门介绍。