微软官方方案：
1、通过分库分表、分库磁盘IO、Share-Disk架构
2、AlwaysOn
第三方软件服务：
1、DBTwin
2、负载均衡产品Moebius For SQL Server
3、数据库路由器软件ICX（提供MS SQL Server数据库服务器的集群功能，可以实现数据库服务器的并行处理、负载均衡和热备份、实时切换。 ）
硬件负载方案
1、F5 +数据池
- 关于镜像复制(发布订阅)
参考链接:
配置复制就没有数据库镜像和AlwaysOn的要求那么高，只需要两台服务器能通过TCP进行通讯即可，两台服务器操作系统和SQL版本都可以不完全一致，而且两台服务器也不需要加入域，所以配置复制订阅就简单多了，但是复制订阅主要是针对数据表而不能像镜像和AlwaysOn那样配置整个数据库，这也是它的缺点吧。
注意：
1.发布的表必须要存在主键和聚集索引，之前遇到过上G级别的表因为没有聚集索引导致订阅失败。
2.一个发布项目不要包含的表不要太大，由于发布生成快照的过程中会锁表同时会堵塞相应表的进程，如果表太大导致生成快照的时间过长势必会导致服务器堵塞非常的严重有时候还会出现很严重的问题！！！，可以通过多创建几个发布项目来解决。
3.发布服务器和分发服务器分开，减少发布服务器的压力。
4.注意一些特殊字符类型的字段会导致创建订阅失败，这里面可以将字段的数据类型改成unicode类型的字段，unicode类型的字段在SQLServer中以N开头，比如nchar、nvarchar、ntext等。
5.如果要创建请求订阅，那么快照文件夹路径需要配置共享文件夹。
SQL Server 高可用方案大全：
SQL Server AlwaysOn:
SQL Server 镜像：
SQL Server 事务日志传输：
SQL Server 复制：
故障转移群集：
SQL Server 2016快照代理过程分析：
- 关于Always On
可用性组支持的复制环境适用于一组离散用户数据库，称为"可用性数据库" 。 可以创建可用性组以实现高可用性 (HA) 或读取缩放。 HA 可用性组是一组共同实现故障转移的数据库。 读取缩放可用性组是一组复制到其他 SQL Server 实例以实现只读工作负荷的数据库。 一个可用性组支持一组主数据库以及一至八组对应的辅助数据库。 辅助数据库 不是 备份。 应继续定期备份您的数据库及其事务日志。
备注: SQL Server 2012开始支持AlwaysOn功能(数据库服务器必须加域); SQL Server 2016开始支持非域AlwaysOn
每组可用性数据库都由一个"可用性副本" 承载。 有两种类型的可用性副本：一个"主副本" 和一到四个"辅助副本"。 它承载主数据库和一至八个"辅助副本" ，其中每个副本承载一组辅助数据库，并用作可用性组的潜在故障转移目标。 可用性组在可用性副本级别进行故障转移。 可用性副本仅在数据库级别提供冗余（针对一个可用性组中的该组数据库）。 故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。
主副本使主数据库可用于客户端的读写连接。 主副本将每个主数据库的事务日志记录发送到每个辅助数据库。 此过程（称为"数据同步"）在数据库级别运行 。 每个次要副本缓存事务日志记录（"硬化" 日志），然后将它们应用到相应的辅助数据库。 主数据库与每个连接的辅助数据库独立进行数据同步。 因此，一个辅助数据库可以挂起或失败而不会影响其他辅助数据库，一个主数据库可以挂起或失败而不会影响其他主数据库。
或者，您可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。
SQL Server 2017 引入了用于可用性组的两种不同的体系结构。 "AlwaysOn 可用性组"提供高可用性、灾难恢复和读取缩放均衡 。 这些可用性组需要群集管理器。 在 Windows 中，故障转移群集提供群集管理器。 在 Linux 中可以使用 Pacemaker。 另一个体系结构是"读取缩放可用性组" 。 读取缩放可用性组为只读工作负荷提供副本，但不提供高可用性。 读取缩放可用性组中没有群集管理器。
在 Windows 上为 HA 部署 Always On 可用性组 需要 Windows Server 故障转移群集 (WSFC)。 给定可用性组的每个可用性副本必须位于相同 WSFC 的不同节点上。 唯一的例外是在迁移到另一个 WSFC 群集时，此时一个可用性组可能会暂时跨两个群集。
HA 配置中会为创建的每个可用性组创建一个群集角色。 WSFC 群集将监视此角色，以便评估主要副本的运行状况。 针对 Always On 可用性组 的仲裁基于 WSFC 群集中的所有节点，而与某一给定群集节点是否承载任何可用性副本无关。 与数据库镜像相反，在 Always On 可用性组中没有见证服务器角色。
下图显示的是一个包含一个主要副本和四个次要副本的可用性组。 支持最多八个辅助副本，包括一个主副本和两个同步提交辅助副本。
搭建前提：
1.将域用户（需要域管理权限）配置为SQLServer服务和代理的启动用户，同时将域用户加入到SQLServer登入用户并赋予sysadmin服务器角色。
2.将域用户加入到在每台SQLServer服务器的本地用户administrator组中
3.先安装好SQLServer实例再搭建故障转移群集，否则如果在安装的过程中有群集节点故障可能导致安装失败。同时安装SQLServer必须使用administrator本地管理员用户进行安装，其它用户可能导致某些功能安装失败！！！
4.将1433、5022端口加入到防火墙
5.由于alwayson对于故障转移群集依赖非常的高，如果有节点由于网络原因节点连接不上会导致alwayson添加数据库失败，保证数据库服务器和域服务器之间的网络顺畅
6.使用windows身份验证的域用户搭建alwayson
安装配置链接:
- 关于Distributed Availability Groups
参考说明:
https://docs.microsoft.com/zh-cn/sql/database-engine/availability-groups/windows/distributed-availability-groupshttps://aws.amazon.com/cn/blogs/china/multi-region-sql-server-deployment-using-distributed-availability-groups/
分布式可用性组是 SQL Server 2016 中引入的一种新功能，作为现有 Always On 可用性组功能的一种变体。
分布式可用性组是一种特殊类型的可用性组，它跨两个单独的可用性组。 加入分布式可用性组的可用性组无需处于同一位置。 它们可以是物理也可以是虚拟的，可以在本地、公有云中或支持可用性组部署的任何位置。 这包括跨域甚至跨平台，例如一个可用性组托管在 Linux，一个托管在 Windows 上。 只要两个可用性组可以进行通信，就可以使用它们配置分布式可用性组。
传统的可用性组在 WSFC 群集中配置资源。 分布式可用性组不会在 WSFC 群集中配置任何内容。 有关它的所有内容都保留在 SQL Server 中。 若要了解如何查看分布式可用性组的信息，请参阅查看分布式可用性组信息。
分布式可用性组要求基础可用性组具有侦听器。 在创建分布式可用性组时，通过 ENDPOINT_URL 参数为其指定已配置的侦听器，而不是像传统可用性组那样，为独立实例提供基础服务器名称（若是 SQL Server 故障转移群集实例 [FCI]，则提供与网络名称资源相关联的值）。 尽管分布式可用性组的每个基础可用性组都具有侦听器，但分布式可用性组不具有侦听器。
下图显示了分布式可用性组的高级视图，该分布式可用性组跨两个可用性组（AG 1 和 AG 2），这两个可用性组配置在各自的 WSFC 群集上。 分布式可用性组总共有四个副本，每个可用性组中两个。 每个可用性组可支持最大数量的副本，因此分布式可用性最多可有 18 个副本。
分布式可用性组的高级视图
可以在分布式可用性组中将数据移动配置为同步或异步。 但是，与传统可用性组相比，分布式可用性组中的数据移动略有不同。 尽管每个可用性组都具有主要副本，但只有一个数据库副本加入可以接受插入、更新和删除的分布式可用性组。 如下图所示，AG 1 为主要可用性组。 其主要副本将事务发送到 AG 1 的次要副本和 AG 2 的主要副本。 AG 2 的主要副本也称为转发器 。 转发器是分布式可用性组中的次要可用性组中的主要副本。 转发器从主要可用性组中的主要副本接收事务，并将其转发到它自己的可用性组中的次要副本。 然后，转发器将更新 AG 2 的次要副本。
分布式可用性组及其数据移动
使 AG 2 的主要副本接受插入、更新和删除的唯一方法是从 AG 1 手动故障转移分布式可用性组。 在前面的图中，因为 AG 1 包含数据库的可写入副本，所以发出故障转移将使 AG 2 成为可以处理插入、更新和删除的可用性组。 有关如何将一个分布式可用性组故障转移到另一个分布式可用性组的信息，请参阅故障转移到次要可用性组。
在这套架构中，区域A负责托管主副本。架构中将存在一套与区域A对应的标准WSFC集群，名为WSFC1，且此集群无需像传统架构那样进行跨区域部署。同步辅助副本同样被托管在区域A内，但最好与主副本分属不同的可用区。主副本位于区域A的可用区1中，同步辅助副本则位于可用区2中。这两个整合都属于名为AG1的独立可用性组的组成部分。副本之间的数据以同步形式传输，且由自动故障转移功能作为故障转移模式。一旦发生故障，自动故障转移将立即启动并将可用区2节点提升为主副本。
最佳实践建议，应用程序应该通过Always On可用性组的监听器配合最新的受支持驱动程序及关键参数（例如 MultiSubNetFailover=True）实现接入，借此促进故障转移，并保证应用程序以无缝方式对接新副本（且不存在任何错误或超时）。此外，我们还需要考虑与仲裁相关的设置，这部分内容将在后文中具体介绍。
架构中的区域B则被视为辅助区域。我们在该区域中配置有第二个辅助副本，其与托管在区域A中的主副本保持异步同步。我们将这套副本命名为forwarder（转发副本）Forwarder是个全新的概念，也是分布式可用性组的核心功能之一。Forwarder负责同步区域B中的各其他副本。
Forwarder的存在，亦是这套优化架构中的关键优势之一。区域A中的主副本只需要将数据异步发送至forwarder，而forwarder又进一步将数据同步或异步发送至区域B中的其他副本。这就减少了存在多个节点时，从区域A到区域B的总体数据传输量；而且由于WSFC1与WSFC2属于相互独立的集群，我们也就不再需要开启大量端口，这将极大降低由此带来的安全风险。
- 关于Moebius for SQL Server
安装步骤:
Moebius的安装非常简便，在装有SQL Server引擎的服务器上直接点击安装包进行安装，安装过程中一直下一步即可。在此就不再多说。
在此交待一下我的测试环境，是两台虚拟机，IP分别为10.0.0.1和10.0.0.2，操作系统和SQL Server的版本分别为Windows Server 2012和SQL Server 2012。安装完成后在Management Studio管理工具中右击数据库，在弹出菜单中即可找到Moebius的菜单，如Figure2所示。
（Figure2：Moebius for SQL Server 2012）
安装完成后，打开配置管理器界面，如Figure3所示。
（Figure3：Moebius for SQL Server 2012）
分别将10.0.0.1和10.0.0.2这两台服务器加入集群，这里可以注意到，Moebius是以数据库为粒度的，相比实例而言，该种粒度会更加灵活，如Figure4所示。
（Figure4：设置数据库）
将10.0.0.1和10.0.0.2两台服务器的数据库分别加入集群后，建立虚拟IP和端口，建立的虚拟IP为10.0.0.15，端口为5000，之后所有前端应用的连接就可以通过该虚拟IP进行了，完全不需要理会后端的架构，可以让前端与后端解耦，如Figure5和Figure6所示。
（Figure5：设置虚拟IP）
（Figure6：设置连接属性）
建立完成后，集群就配置好了，效果如Figure7所示。
- 数据库路由器
