SQL Server底层架构技术对比
背景
数据库是信息化的基石，支撑着整个业务系统，发挥着非常重要的作用，被喻为“IT的心脏”。因此，让数据库安全、稳定、高效地运行已经成为IT管理者必须要面对的问题。数据库在底层架构层面需要满足以下几点建设要求：
安全和可靠：不能因为服务器的软硬件故障导致数据丢失和业务中断；
容灾：多数据中心间的数据库同步，某一个数据中心出现故障后，可以在另一个数据中心快速拉起业务；
读写分离（报表分离）：把接口程序、报表程序、集成平台数据抽取、大数据运算等高消耗的查询语句分离到备机执行，从而避免对主服务器的性能消耗以及造成的阻塞和死锁；
负载均衡：需要多台服务器同时负载并发请求，降低单台服务器的压力，提升系统整体性能；
弹性扩展：通过增加服务器的方式应对数据量或者访问量增加带来的性能瓶颈。
基于共享存储的双机
两台数据库服务器上的SQL Server共享存储设备中的一份数据库文件，为了防止数据混乱，由主节点控制存储设备，备节点的SQL Server服务处于停止状态。当主节点出现故障后，备节点接管存储设备、启动SQL Server服务、初始化数据库、接管虚拟IP等资源完成故障转移，保障数据库的可用性。SQL Server失败转移群集属于这类技术。
数据安全：只有一份数据，无法保障数据安全。
数据同步验证：只有一份数据，无法验证。可用性：满足。故障转移时间：在故障转移过程中，备节点需要启动SQL Server服务、初始化数据库，当数据库个数多尤其是日志量大的时候，初始化数据库的时间会变长，导致切换时间变长，一般的切换时间在20秒以上。读写分离：只有一个节点运行，无法实现。负载均衡：只有一个节点运行，无法实现。
基于磁盘镜像的双机
两台服务器中的SQL Server独立安装，使用各自磁盘中的数据库文件，利用磁盘镜像技术，主节点磁盘上的数据变化实时同步到备节点的磁盘中。为了防止数据混乱，备节点的SQL Server服务处于停止状态。当主节点出现故障后，备节点启动SQL Server服务、初始化数据库、接管虚拟IP等资源完成故障转移，保障数据库的可用性。
数据安全：SQL Server层面有两份数据库文件，可以保障数据安全。在大数据量写入时突然掉电关机的极端情况下，写入磁盘的SQL Server数据格式不完整导致SQL Server出现逻辑错误，重启后数据库出现质疑，因为两份数据一模一样，因此备节点上也会出现相同的现象。
数据同步验证：备节点上的SQL Server服务是不能启动的，无法随时进行数据验证。要想验证数据，需要对当前时间点做快照，然后启动SQL Server服务，加载数据库后进行验证，验证后停止SQL Server服务，移除快照，操作非常麻烦，否则就得进行节点切换来验证，切换时对应用有影响。可用性：满足。故障转移时间：在故障转移过程中，备节点需要启动SQL Server服务、初始化数据库，当数据库个数多尤其是日志量大的时候，初始化数据库的时间会变长，导致切换时间变长，一般的切换时间在20秒以上。读写分离：只有一个节点运行，无法实现。负载均衡：只有一个节点运行，无法实现。
容灾
和基于磁盘镜像的双机一样，容灾软件也是利用磁盘镜像技术，主节点磁盘上的数据变化实时或者准实时同步到容灾节点的磁盘中，不同的是基于容灾场景下功能的增强，例如传输过程中的压缩和加密，利用快照功能做CDP（数据保护），有的容灾软件也带有可用性的功能。
存储双活
和主机高可用一样，为了防止存储设备单点故障而出现的高可用技术，并演化为“双活”，主要有通过存储网关同时写入两个存储设备或者存储设备间数据复制两种实现方式。和磁盘RAID一样，存储双活对于上层应用来说是透明的，底层数据有两份，但是对于SQL Server来说还是看到的是一份数据库文件。有人认为两个SQL Server服务器分别接到配置了双活的两个存储设备上就能实现两个SQL Server数据库间的同步，这是一个非常大的误区。
数据安全：底层有两份数据，可以保障数据安全。对于上层的SQL Server还是一份数据，因此存储双活也无法解决在大量数据写入时突然掉电关机导致的数据库质疑问题。
数据同步验证：SQL Server层面还是一份数据，无法进行数据同步验证。可用性：只能保障数据文件层面的可用性，SQL Server层面的可用性还需要借助其他技术实现。故障转移时间：取决于SQL Server层面使用的高可用技术。读写分离：无法实现。负载均衡：无法实现。
虚拟化\超融合
虚拟化技术是一种资源管理技术，可实现物理层与逻辑层的分离，提高IT基础设施管理效率和资源利用率。从SQL Server层面来看依然只有一个节点。超融合是虚拟化技术的延伸，更多的体现在软硬件一体化，不做过多的介绍，可以当作虚拟化来看待。
数据安全：存储层面有两份数据，可以保障数据安全。对于上层的SQL Server还是一份数据，因此也无法解决在大数据量写入时突然掉电关机导致的数据库质疑问题。
数据同步验证：从SQL Server层面上看只有一个节点、一份数据库文件，无法在SQL Server层面进行数据验证。可用性：虚拟化技术基本都有高可用功能，当物理服务器发生故障的时候，受影响的虚拟机将在集群中留有备用容量的其它物理服务器上自动启动。故障转移时间：搭配高级HA功能的可以做到状态和数据在主备机间实时同步，故障时快速切换。读写分离：SQL Server层面只有一个节点，不能实现。负载均衡：SQL Server层面只有一个节点，不能实现。
发布订阅
发布订阅是SQL Server提供的数据库复制技术，可用作数据同步、冷备、读写分离等。分快照复制、事务复制、对等复制、合并复制几种方式，这里用经常使用的事务复制进行说明。事务复制是单向的主从复制，主要有以下特点：
-
数据同步是异步的，变更的数据几秒钟后才能同步到订阅服务器；
-
不是整库的同步，需要对同步的对象（表、视图、存储过程、函数等）进行配置；
-
参与复制的表要有主键，而且不能有TRUNCATE TABLE操作；
-
对对象进行DROP操作时，要先从发布订阅中移除；
-
部署比较麻烦，易出错。
数据安全：在SQL Server层面有两份或者多份数据，但是数据同步是异步的，有几秒钟的延迟，而且不是整库的同步，丢失数据的风险很高。
数据同步验证：订阅服务器上的数据库是可以查询的，可以随时执行SQL语句进行验证。可用性：没有虚拟IP地址、自动故障切换等可用性的功能。读写分离&负载均衡：订阅服务器上的数据库是可以查询的，可以把高消耗的报表类的查询分离到订阅服务器中，但是需要修改应用程序实现“读写”和“只读”两种数据库连接。负载均衡：需要借助负载均衡软件或硬件。
AlwaysOn
AlwaysOn是SQL Server 从2012版本开始推出的多个实例间同步数据库的技术，借助Windows失败转群集实现高可用，主副本出现故障后，自动切换到辅助副本。辅助副本中数据库都是可以查询的，可用来实现读写分离、负载均衡等功能。
AlwaysOn中每个副本的SQL Server服务独立安装，使用每个副本自己存储介质内的数据库文件。在主副本写入数据时会产生日志，AlwaysOn捕获并传输日志到其他副本，并通过REDO技术完成日志到数据的转换，从而实现各副本中数据的一致性。有同步提交和异步提交两种同步方式，不同的副本可以使用不同的同步方式。
数据安全：在SQL Server层面有两份或者多份数据，可以保障数据安全。AlwaysOn同步日志数据时有数据格式的校验，不会同步不完整的日志，在大数据量写入时突然掉电关机，主节点数据库出现质疑时，辅助节点不会。
数据同步验证：每个节点上的SQL Server服务都是开启的，数据都是可供使用的，可以随时执行SQL语句进行验证。可用性：AlwaysOn不支持对实例级别的对象同步，例如登录账号、作业、链接服务器、系统数据库对象，需要人工维护，靠人工的方式保障每个副本的一致性是很困难的。在实践过程中发现，辅助副本切换成主副本时，因为账号不对、密码不对、权限不对、数据库映射关系不对、作业不对、系统对象不对等各种原因导致业务系统无法正常使用的情况非常普遍。故障转移时间：副本转移时不需要经过数据库初始化的过程，切换速度快，少于10秒。读写分离：辅助副本的数据库是可以查询的，可以把高消耗的报表类的查询分离到辅助副本中。在AlwaysOn下实现读写分离，应用程序建立数据库连接时使用的数据库连接字符串中加上“ApplicationIntent=ReadOnly”关键词，AlwaysOn把该连接建立到辅助副本。重要的前提是该连接里面所有的SQL语句都必须是只读的，如果有更新的SQL语句，就会报错。也就是说AlwaysOn的读写分离是连接级的，不是语句级的。很多人认为只要在数据库连接串中加好这个关键词，不需要改动应用程序就能实现读写分离，这是个非常大的误区。要修改应用程序实现“读写”和“只读”两种数据库连接。这个改造过程对于自己研发的产品来说是容易的，如果是购买的第三方产品，难度就可想而知了。负载均衡：SQL Server 从2016版本开始实现了负载均衡，前提是应用程序先实现读写分离。AlwaysOn的负载均衡策略是静态的轮询机制，不管副本压力如何，都按照顺序轮询在每个副本中建连接。AlwaysOn的调度是连接级的，不是语句级的，连接建立后，不管该副本压力如何，连接内的语句都要在该副本中执行。
Moebius
Moebius采用“share nothing”架构，每个节点的SQL Server服务独立安装，使用每个服务器自己存储介质内的数据库文件。不基于共享存储设备，也不基于磁盘镜像等功能，通过SQL Server的日志同步技术实现各节点中数据的一致性。在主节点写入数据时会产生日志，Moebius捕获并传输日志到其他节点，并通过REDO技术完成日志到数据的转换。因此每个节点的SQL Server服务都是启动的，数据都是“活”的。
Moebius的调度引擎支持连接级和SQL语句级两种调度方式，通过规则的配置，在不改动或者少改动应用程序的前提下，透明的完成读写分离、负载均衡。
数据安全：在SQL Server层面有两份或者多份数据，可以保障数据安全。Moebius同步日志数据时有数据格式的校验，不会同步不完整的日志，在大数据量写入时突然掉电关机，主节点数据库出现质疑时，辅助节点不会。
数据同步验证：每个节点上的SQL Server服务都是开启的，数据都是可供使用的，可以随时执行SQL语句进行验证。可用性：支持数据库和实例级对象（登录账号、作业、链接服务器、系统库对象等）的同步，满足真正的高可用。故障转移时间：节点转移时不需要经过数据库初始化的过程，切换速度快，少于10秒。读写分离：每个节点上的SQL Server服务都是开启的，数据都是可供使用的。Moebius的调度引擎支持语句级的解析，只需要修改应用程序的数据库连接串让应用程序连接到Moebius集群的端口，在Moebius中配置基于语句特征的相关规则就可以在不修改或者少修改应用程序的前提下实现读写分离。Moebius支持SQL语句、登录名、客户端主机名、应用程序名等多个维度进行规则的配置。负载均衡：Moebius是基于节点压力状况的动态负载均衡策略，调度引擎定期缓存每个节点的负载情况（CPU利用率、IO性能指标、请求数等），应用程序执行查询语句时，调度引擎选择到压力较小的节点执行。
总结
从根本上说是通用技术和SQL Server专用技术的比较，如果要实现数据安全和可用性等基本需求，通用技术就能可以做到，如果要实现读写分离、负载均衡等高级别的需求，就需要充分利用SQL Server特性而开发的专用技术。并不是说通用技术不好，只是满足的场景不同而已，我们要根据实际的场景选择合适的方案。
