应用程序使用Listener的虚拟网络名连接SQL Server实例，是以一个默认实例的形式访问的，只有服务器名，没有SQL Server实例名，因此应用程序不会尝试使用SQL Brower 服务。推荐AlwaysOn的各个副本都使用默认实例，默认端口。如果Listener使用的端口号是默认端口1433，那么应用程序能够直接使用虚拟网络名连接到SQL Server实例。
二，AlwaysOn的数据同步原理
AlwaysOn会在各个副本上维护数据库的副本，主副本上发生的数据更新，都会同步到辅助副本上，为了实现数据同步，AlwaysOn需要完成三个任务：
把主副本上发生的数据更新的事务日志记录下来；
把事务日志记录传输到各个辅助副本；
在各个辅助副本上重做数据更新；
在主副本和辅助副本上，SQL Server都会启动相应的线程来完成相应的任务。
1，日志持久化
任何一个SQL Server都有个Log Writer线程，当事务提交一个数据更新时，Log Writer把数据更新的日志写入到物理事务日志文件。
2，主副本的日志传输
对于配置AlwaysOn 主副本的数据库，SQL Server创建一个Log Scanner线程，负责将日志记录从日志缓冲区或者事务日志文件读出，打包成日志块，发送到各个辅助副本，由于Log Scanner线程的不间断工作，使得主副本上的数据变化，不断地向辅助副本上传播。
3，辅助副本上的固化（Harden）和重做（Redo）
在辅助副本上，同样有两个线程固化线程和重做线程完成相应的数据更新操作。固化线程将主副本上Log Scanner传入的日志块写入辅助副本的硬盘上的事务日志文件里，而重做线程，负责从硬盘上读取事务日志，将日志记录翻译成数据更新操作，在辅助副本的数据库上重做主副本的数据更新操作。
当重做线程完成工作之后，辅助副本上的数据库和主副本保持同步，重做线程每隔固定的时间间隔，就会向主副本报告自己的工作进度，主副本根据各个辅助副本的工作进度，就能计算数据的差异。
在AlwaysOn中，在固化线程和重做线程是完全独立工作的，固化线程负责将主数据库传递的日志写入到硬盘上的日志文件中，将日志持久化存储；而重做线程负责读取和翻译已被固化线程存储的日志，将主数据库上的数据更新操作在辅助数据库上重新执行。
三，AlwaysOn的可用性模式
可用性模式决定了主副本在提交事务之前，是否需要等待某个辅助副本将事务日志记录固化到硬盘，AlwaysOn可用性组支持两种可用性模式：异步提交模式和同步提交模式。
1，异步提交模式
当辅助副本处于异步提交模式时，主副本无需等待辅助副本完成日志固化，就可以提交事务，因此，主副本事务提交不会受到辅助数据库的影响而产生等待，但是，辅助数据库的更新会滞后于主数据库，如果发生故障转移，可能会导致某些数据更新丢失。
在异步提交模式下，辅助副本会尽量和主副本的日志记录保持一致，不过，即使辅助数据库和主数据库上的数据是同步的，可用性组始终认为辅助数据库处于“在同步”（SYNCHRONIZING）状态，因为，理论上在异步模式下，辅助数据库在任何时间点都可能滞后于主数据库。
2，同步提交模式
在同步提交模式下，主数据库在提交事务之前，主副本必须等待辅助副本将日志固化到硬盘上，主副本只有收到来自辅助副本的日志固化成功的确认信息之后，才能提交事务；只要辅助副本没有向主副本报告日志固化完成，主副本上的事务就不能提交。这样能够保持主副本和辅助副本的数据始终是同步的，只要一直进行数据同步，辅助数据库就会保持”已同步“（SYNCHRONIZED）状态。
同步提交模式能够实现辅助数据库和主数据库上的数据的完全同步，但是，代价是主数据库上的事务提交延迟增加，可以说，同步提交模式相对于性能来说，更强调高可用性。
3，可用性副本之间的短线连接状态
”DISCONNECTED“连接状态：AlwaysOn可用性组之间有一个会话超时机制，默认值10s。主副本和辅助副本之间，按固定的时间间隔相互发送ping，在会话超时时间内，如果主副本收到辅助副本的ping命令，就说明副本之间的连接正常；一旦某个辅助副本因为故障而不能响应，产生会话超时，主副本将该辅助副本的连接设置为”DISCONNECTED“连接状态，即使使用同步提交模式，主副本的事务也不需要等待该副本的响应就可以提交。
4，辅助数据库的”NOT SYNCHRONIZING“状态