微軟官方方案：
1、通過分庫分表、分庫磁盤IO、Share-Disk架構
2、AlwaysOn
第三方軟件服務：
1、DBTwin
2、負載均衡產品Moebius For SQL Server
3、數據庫路由器軟件ICX（提供MS SQL Server數據庫服務器的集群功能，可以實現數據庫服務器的並行處理、負載均衡和熱備份、實時切換。 ）
硬件負載方案
1、F5 +數據池
-
關於鏡像復制(發布訂閱)
參考鏈接:
https://www.cnblogs.com/chenmh/p/4487766.html
配置復制就沒有數據庫鏡像和AlwaysOn的要求那么高，只需要兩台服務器能通過TCP進行通訊即可，兩台服務器操作系統和SQL版本都可以不完全一致，而且兩台服務器也不需要加入域，所以配置復制訂閱就簡單多了，但是復制訂閱主要是針對數據表而不能像鏡像和AlwaysOn那樣配置整個數據庫，這也是它的缺點吧。
注意：
1.發布的表必須要存在主鍵和聚集索引，之前遇到過上G級別的表因為沒有聚集索引導致訂閱失敗。
2.一個發布項目不要包含的表不要太大，由於發布生成快照的過程中會鎖表同時會堵塞相應表的進程，如果表太大導致生成快照的時間過長勢必會導致服務器堵塞非常的嚴重有時候還會出現很嚴重的問題！！！，可以通過多創建幾個發布項目來解決。
3.發布服務器和分發服務器分開，減少發布服務器的壓力。
4.注意一些特殊字符類型的字段會導致創建訂閱失敗，這里面可以將字段的數據類型改成unicode類型的字段，unicode類型的字段在SQLServer中以N開頭，比如nchar、nvarchar、ntext等。
5.如果要創建請求訂閱，那么快照文件夾路徑需要配置共享文件夾。
SQL Server 高可用方案大全：
SQL Server AlwaysOn:http://www.cnblogs.com/chenmh/p/4484176.html
SQL Server 鏡像：http://www.cnblogs.com/chenmh/p/4452902.html
SQL Server 事務日志傳輸：http://www.cnblogs.com/chenmh/p/3671030.html
SQL Server 復制：http://www.cnblogs.com/chenmh/p/4487766.html
故障轉移群集：http://www.cnblogs.com/chenmh/p/4479304.html
SQL Server 2016快照代理過程分析：http://www.cnblogs.com/chenmh/p/7895991.html
-
關於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
安裝配置鏈接:
https://www.cnblogs.com/jerviscui/p/10895095.html
https://www.cnblogs.com/cuihongyu3503319/p/10651904.html
https://blog.csdn.net/kk185800961/article/details/69934624
-
關於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所示。
參考鏈接:
https://www.cnblogs.com/MuNet/p/5762020.html
-
數據庫路由器