原文:SQL Server AlwaysOn中的几个误区
AlwaysOn自SQL Server2012之后已经发布很久了，最近我在给一些客户做咨询的时候经常被问起是不是应该使用AlwaysOn，从客户的视角来看仿佛AlwaysOn是一个包治百病的良药，但实际上没有包治百病的良药。因此在此我谈一谈AlwaysOn中的常见误区。
1.AlwaysOn可以实现负载均衡。
答案是否定的，AlwaysOn在特定条件下（需要修改前端应用程序）可以负担只读负载，但负载均衡是无法做到的。在SQL Server中如果希望实现负载均衡可以考虑两个方向，通过复杂的架构以及和修改应用程序来共同实现，可以考虑的方向诸如：
可伸缩共享数据库
该特性允许多个SQL Server实例连接到一个共享的只读存储，从而使得报表服务可以Scale-Out，但只能扩展只读负载，拓扑图如图1所示。
图1.可伸缩共享数据库
对等复制
对等复制允许节点中的每一个点进行更新。但对等复制有比较严格的限制，包括每个节点可更新的数据库范围的考虑、冲突的处理、对网络带宽的要求、对运维人员水平的要求、对丢失数据方面的考虑等，典型拓扑图如图2所示。
图2.对等复制拓扑
分布式视图
简单理解，分布式视图就是将数据分布到多个节点，通过视图将这些数据汇总起来。这种方案需要对程序做大量修改，比较麻烦。
SQL Server Service Borker(SSB)
说到这个方案，我曾经因为这个方案吃过不少苦头。该方案实施起来过于复杂，并且需要应用程序端针对做大量修改，经常掉消息。没有专业的DBA来看就是自寻死路。
考虑第三方方案
SQL Server一直没有原生的负载均衡方案，如果自己没有很强大的实力或是使用的是第三方厂商提供的产品无法修改代码，可以考虑第三方方案，国内我知道一家公司，格瑞趋势(http://www.grqsh.com/)专门做SQL Server上的负载均衡的方案。我在微软举办的一次活动中和他们的数据库咨询顾问交流过，水平还不错。
2.AlwaysOn是一个Share-Nothing方案
只说对了一半。实际上，AlwaysOn中包含两种方案，AlwaysOnFailover Cluster Instance可以看作之前SQL Server故障转移集群的升级版本，升级的部分包括更灵活的故障转移策略、可以将TempDB放到本地存储等特性。该方式是共享磁盘的解决方案。
另一部分是AlwaysOnAvailability Group是Share-Nothing的方案，可以看作之前镜像的升级版本，只是副本可以同时存在4个（SQL Server 2014中是8个）并且允许只读。
3.AlwaysOn是以一组数据库为粒度，则可以执行针对改组数据库的跨库事务
不允许。虽然可用性组是以多个库为粒度，但不允许事务中更新的数据涉及到AlwaysOn中的多个库。
4.AlwaysOn中的每个节点都必须在物理机上
错误，实际上，AlwaysOn的WSFC也可以在虚拟环境中。
5.AlwaysOn可用性组的性能会比镜像高很多
这也同样是一个常见的误区，或许和微软对AlwaysOn的宣传有关，我咨询过的一些客户都受到过微软号称AlwaysOn包治百病，但实际上AlwaysOn是基于镜像，如果您的网络或IO性能存在问题，那么即使使用了AlwaysOn可用性组性能也会存在问题。