Alwayson是微软从SQL2012开始引入的一种高可用和高性能架构，它既可以实现故障转移，同时又能实现查询分离，是当前SQL server的所有架构中最优秀的一种。
因此，一般我们都会推荐使用AlwaysON来部署生产数据库，不过，尽管AlwaysON的优势非常明显，但并非适应于所有的业务场景。
AlwaysON不支持分布式事务和跨数据库事务
什么是分布式事务和跨数据库事务
分布式事务是指通过分布式事务协调器（MSDTC）的统一控制、将事务中的每个操作分解到多台主机上分别执行、每台主机执行成功后整个事务才能提交的事务，分布式事务协调器用来保证数据的一致性。跨数据库事务与此类似，只是不会用到MSDTC，而是将DBID最小的一个作为分布式事务协调器。
为什么AlwaysON不支持分布式事务
如果在一个分布式事务执行期间AlwaysON发生了故障转移，AG服务从主副本转移到了辅助副本，分布式事务协调器因为收不到原主副本的事务提交确认信息，认为事务执行失败，然后将其他参与（分布式事务的）节点上的应要提交的事务回滚。对于新的主副本，因为没有参与之前的分布式事务，因此无法从分布式事务协调器获取事务的状态，继续维持现有的数据不变化，从而导致新副本与参与分布式事务的其他节点上的数据不一致。
备注：跨数据库事务的原因与此类似。
下面我们通过图例来展示这个过程：
下图：假设有ABC三个节点，AC之间做了AlwaysON，其中A.table1中a的初始值为0，B.table1中a的初始值为1000。有一个分布式事务1，需要将节点A的表中a加上1000，同时需要在节点B的表中a减去1000。
BEGIN TRAN
Update A.table1 set a=a+1000 ;
Update B.table1 set a=a-1000 ;
COMMIT TRAN
正常情况下，最后的结果应该是A.table1.a=1000，B.table1.a=0,，C.table1.a=1000。
现在有这样一个场景，A和B都已经commit，A.table1.a=1000，B.table1.a=0，且A已经将事务1的操作通过日志同步到了主机C，C.table1.a=1000。
正常情况下，主机A和B都向事务协调器发送commit ack（提交确认）信息，事务协调器收到两者的确认信息后就可以将整个事务标记为提交。但现在A在发送commit ack信息时发生了宕机，分布式事务协调器只收到了主机B的commit ack，于是协调器将整个事务标记为失败，然后在主机B上回滚事务1的操作，此时B.table1.a=1000。
节点C虽然接管了AlwaysON集群，因为它并不是分布式事务的执行者之一，所以它无法从分布式事务协调器获取事务1的状态，因此它不会回滚，a的值保持不变。最后C.table1.a=1000、B.table1.a=1000，发生了数据不一致的问题。
参考文章：
https://msdn.microsoft.com/en-us/library/ms366279(v=sql.110).aspx;
AlwaysON的主副本使用传统的SQL Server故障转移集群
从上文可以看到，AlwaysON不支持分布式事务（和跨数据库事务）的根本原因在于主副本故障转移到辅助副本时会造成分布式事务执行不一致。
解决这个问题的焦点就是主副本和辅助副本的故障转移。如果主副本与辅助副本之间不允许故障转移（也就是处于异步同步模式下），辅助副本的职责只是接受来自主副本的日志，然后执行redo实现同步，这样一来就不会产生异常数据。
不过，主、辅副本无法故障转移后，主副本存在单点故障的风险，为了避免此类情况发生，我们可以为主副本建立传统的SQL Server故障转移集群。在这种架构下，如果主节点在执行分布式事务发生了故障转移，辅节点接管的SQL实例是原主节点的同一个实例，而且数据文件和日志文件是相同的，所以不会与其他参与分布式事务的节点产生数据不一致的问题。
