1、SQLServer高可用方案企业选型
SQLServer高可用介绍：
SQLServer以前的高可用方案：
数据库镜像、复制订阅、HA（故障转移群集）
SQLServer现在的高可用方案：
AlwaysOn
从SQLServer 2012以后微软推出了新的SQLServer高可用技术 ，它的名字叫AlwaysOn。
AlwaysOn是一种集合了高可用性和灾难恢复两种功能于一体的技术，相比故障转移群集、数据库镜像和复制订阅拥有许多优势，所以现在这种高可用方案被企业广泛的应用于生产环境中。
2、SQLServer高可用架构AlwaysOn企业实践
AlwaysOn可用性组是SQLServer 2012中提供的全新功能，确保了应用程序数据的可用性，实现零数据丢失，AlwaysOn可用性组技术融合了数据库集群和数据库镜像的优点，此技术的一大好处是提供非共享存储，可以避免因为存储的单点故障而造成的整个可用性方案失效。
现在的 SQLServer 2014AlwaysOn、SQLServer 2016 AlwaysOn最多可以支持9个副本，但只有一个可用性副本上运行的数据库是处于可读写状态。
AlwaysOn是一种整库同步的技术，所有的成员服务器都维护一套相同的数据库副本。当主副本上的数据发生变化时，数据会实时同步到辅助副本上。这点与数据库镜像非常类似。
下图详细描述了AlwaysOn数据同步的整个过程，我们先来看看每个步骤所代表的意义。
①主副本的logwriter把事务修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化）；
②主副本的logscanner从缓存中或者日志文件中读取日志块，然后把它发送给AlwaysON的日志块解码器；
③主副本将日志块通过网络传送给辅助副本；
④和⑤
辅助副本接受到日志块后，logwriter把事务修改的日志信息先记入一段内存中的日志缓冲区，然后再写入物理日志文件（日志固化），另外，如果辅助副本处于同步可用模式时，在日志固化后，还必须反馈信息给主副本，主副本在接受到辅助副本完成固化的消息后才可以提交该事务，如果辅助副本在异步可用模式或者主副本在异步模式下，主副本提交事务与否跟辅助副本是否完成日志固化没有关系，下文在介绍可用模式时会详细介绍；
⑥重做（Redo）线程将日志中记录的事务在辅助副本上重新演绎。重做线程每隔固定的时间点，会跟主副本通信，告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。
AlwaysOn分为同步提交和异步提交模式，同步提交模式下的副本可以用于故障转移（高可用），异步提交模式下的副本一般作为只读副本和容灾。
下图显示的是具有五个可用性副本的可用性组。主副本和一个辅助副本配置为使用同步提交模式以及自动故障转移。另一个辅助副本配置为使用同步提交模式且仅限计划的手动故障转移，两个辅助副本配置为使用异步提交模式，其仅支持强制手动故障转移（一般称为“强制故障转移”）。
两个可用性副本之间的同步和故障转移行为取决于这两个副本的可用性模式。例如，对于要发生的同步提交，涉及的当前二手域名出售地图主副本和辅助副本必须配置为同步提交。同样，对于要发生的自动故障转移，需要将这两个副本配置为自动故障转移。因此，上述部署方案的行为可用下表概括，它揭示了每个潜在主副本的行为：
通常，节点 04 在灾难恢复站点中作为异步提交副本部署。事实上，由于两个节点之间的高网络延迟，在故障转移到节点 04 后节点 01、02 和 03 仍处于异步提交模式，这帮助防止潜在的性能下降。
故障转移场景可见下图：
在主副本变得不可用之后，自动故障转移将导致合格的辅助副本自动转换为主角色。当承载主副本的 WSFC 节点对于承载辅助副本的节点而言为本地节点时，自动故障转移最适合。这是因为数据同步最适合于计算机之间的低消息延迟时间情况以及因为客户端连接可以保持为本地。
在数据库管理员针对承载目标辅助副本的服务器实例发出手动故障转移命令后，手动故障转移将导致已同步的辅助副本转换为主角色。
强制故障转移会启动一个将主角色转换为角色处于辅助或正在解析状态的目标副本的过程。故障转移目标成为新的主副本，并立即将其数据库副本提供给客户端。当以前的主副本变得可用时，它将转换为辅助角色，并且其数据库将成为辅助数据库。
对可用性组强制进行故障转移（可能丢失数据）是一种灾难恢复方法，使您能够将辅助副本用作温备用服务器。因为强制故障转移存在数据丢失的风险，所以应该谨慎使用。建议仅当您必须立即将服务还原到可用性数据库并愿意承担数据丢失的风险时，才执行强制故障转移。
对于数据量未达TB级别以上的公司而言， SQLServer的AlwaysOn无疑是一个不错的数据库高可用解决方案。
即使数据量达到了TB级别以上， SQLServer的AlwaysOn也可以辅以其他中间件和缓存来实现整体的数据库解决方案。
