高可用性（按服务层级划分）
若要了解 Azure SQL 中的可用性选项和功能，需要了解服务层。 所选的服务层级将确定所部署的数据库或托管实例的基础体系结构。
有两种购买模型可供选择：DTU 和 vCore。 本单元将重点关注 vCore 服务层级及其体系结构以实现高可用性。 可以将 DTU 模型的基本层级和标准层级等同于常规用途，将高级层级等同于业务关键。
常规用途
常规用途服务层级中的数据库和托管实例具有相同的可用性体系结构。 以下图为指南，首先考虑“应用程序”和“控件环”。 应用程序连接到服务器名称，后者连接到 VM 上运行的网关 (GW)，该网关将应用程序的连接指向正确的服务器。 在常规用途层级中，主要副本将本地附加的 SSD 用于 tempdb。 数据和日志文件存储在 Azure 高级存储中，即本地冗余存储（在一个区域中有多个副本）中。 然后，备份文件存储在 Azure 标准存储，即默认为 RA-GRS。 RA-GRS 是在多个区域都有副本的全局冗余存储。
如学习路径中的早期模块中所述，所有 Azure SQL 都是基于 Azure Service Fabric 构建的，用作 Azure 主干。 如果 Azure Service Fabric 确定需要进行故障转移，则该故障转移将类似于故障转移群集实例 (FCI) 的故障转移。 服务结构将查找具有备用容量的节点并启动新的 SQL Server 实例。 然后将附加数据库文件，运行恢复，并更新网关以将应用程序指向新节点。 不需要虚拟网络或侦听器或更新。 此功能是内置的。
业务关键
下一个要考虑的服务层级是业务关键，该层级通常可以实现所有 Azure SQL 服务层级（常规用途、超大规模、业务关键）的最高性能和可用性。 业务关键适用于需要低延迟和最短宕机时间的任务关键型应用程序。
使用业务关键类似于在后台部署 Always on 可用性组 (AG)。 与常规用途层级不同，业务关键层级中的数据和日志文件均在直接附加的 SSD 中运行，可显著降低网络延迟。 （常规用途使用远程存储。）该 AG 中有三个次要副本。 可以使用其中一个作为只读终结点（无需另行付费）。 只要有一个辅助副本为其事务日志强制写入了更改，事务就可以完成提交。
使用次要副本之一的读取扩展支持会话级一致性，因此，如果只读会话在发生连接错误（因副本不可用而导致）后重新连接，可以使用读写副本将其重定向到并非完全处于最新状态的副本。 同样，如果应用程序使用读写会话写入数据，然后使用只读会话立即读取数据，则最新更新可能不会立即显示在副本上。 延迟是由异步事务日志恢复操作导致的。
如果发生了任何类型的故障，且 Service Fabric 确定需要进行故障转移，则故障转移到次要副本会非常快，因为该副本已存在并且已附加数据。 在故障转移中，无需使用侦听器。 即使发生了故障转移，网关也会将你的连接重定向到主要副本。 这种切换会快速进行，然后 Service Fabric 会运转另一个次要副本。
超大规模
超大规模服务层级仅在 Azure SQL 数据库中可用。 此服务层有一个独特的体系结构，因为它使用一个分层的缓存和页面服务器层来扩展快速访问数据库页面（而无需直接访问数据文件）的功能。
由于该体系结构使用配对的页面服务器，因此你可以横向扩展，从而将所有数据放入缓存层。 这一新体系结构还允许超大规模支持高达 100 TB 的数据库大小。 由于它使用快照，因此几乎可以在不考虑大小的情况下进行即时的数据库备份。 数据库还原只需几分钟而不是几小时或几天。 你还可以在固定时间内进行纵向扩展或缩减，使其满足工作负载需求。
值得探讨的部分在于，如何在该体系结构中拉取日志服务。 日志服务用于为副本和页面服务器推送信息。 事务可以在日志服务强制写入登陆区域时提交，因此无需使用辅助计算副本进行的更改即可完成提交。 不同于其他服务层，你可以确定是否需要次要副本。 可以配置零到四个次要副本，所有这些副本都可用于读取缩放。
与在其他服务层级中一样，如果 Service Fabric 确定需要进行自动故障转移，则会执行这种故障转移，但恢复时间取决于次要副本是否存在。 例如，如果没有副本并且发生了故障转移，则场景将类似于常规用途服务层级：Service Fabric 首先需要找到备用容量。 如果你有一个或多个副本，则恢复速度会更快，并且会与业务关键服务层级中的速度更加一致。
业务关键服务层级为需要低延迟的、日志写入量较小的工作负载保持最高性能和可用性，但超大规模服务层级允许你获得更高的日志吞吐量（以 MB/秒为单位），提供最大的数据库大小，并提供最多四个次要副本来实现更高级别的读取规模。 因此在两者之间进行选择时需要考虑工作负载的情况。