个人觉得sqlserver貌似没有专门针对负载均衡的组件，最近看了点联机丛书，貌似通过复制+负载均衡器可以实现基本的负载均衡问题。
有如下疑问不知怎么解决：
1、貌似延时最短的是事务复制，我进行了实验，即使是在本机上装上两个实例，这样的延时也有几秒，在这几秒内两边
数据库的数据是不一致的，若在这边的数据库插入数据，又在那边进行查询，问题就出现了！怎么解决？
2、可更新的分布事务为了解决冲突，延时一定会更长，怎么解决？高手赐教，在线结贴，顶者有分！
有如下疑问不知怎么解决：
1、貌似延时最短的是事务复制，我进行了实验，即使是在本机上装上两个实例，这样的延时也有几秒，在这几秒内两边
数据库的数据是不一致的，若在这边的数据库插入数据，又在那边进行查询，问题就出现了！怎么解决？
2、可更新的分布事务为了解决冲突，延时一定会更长，怎么解决？高手赐教，在线结贴，顶者有分！
他们的实现原理是这样的：和SQL Server镜像一样，每个数据库节点都有自己的数据，也就是无共享磁盘架构。他们称之为“中间件”的程序宿主在数据库的内部，每个节点数据库上写入数据导致数据变化时，SQL Server会激活“中间件”，“中间件”把变化的数据同步到其他的节点上。其他节点发生变化也是一样。因为“中间件”宿主在数据库内，所以它能够把每个同步的Session和SQL Server的Session绑定到一起，也就是使用户的执行和数据的同步成为一个原子操作，从而保证数据在每时每刻都是一致的。因此查询可以随便到每个机器上去查，从而做到了真正的负载均衡
1、实现原理
实现数据库的负载均衡技术，首先要有一个可以控制连接数据库的控制端。在这里，它截断了数据库和程序的直接连接，由所有的程序来访问这个中间层，然后再由中间层来访问数据库。这样，我们就可以具体控制访问某个数据库了，然后还可以根据数据库的当前负载采取有效的均衡策略，来调整每次连接到哪个数据库。好处在两个方面:首先，它成功地将数据库放到了内网之中，更好地保护了数据库的安全性。如果数据库也在公网上，1433端口是很容易被攻击的，所以要保护数据库与之的连接，就用到了中间层。它可以将数据库更加好地保护在内网。其次，对应用来说完全透明，集群暴露出来的就是一个IP ，连接数据库的所有连接都可以控制，更方便DBA对数据的管理，看哪些连接更耗费数据库资源，以便更好地优化代码。
但是，也有两点要注意:第一，必须要做成Windows的服务程序。Windows发展到今天，如果以一个集成的大系统来讲，做成服务程序更加稳定，也更加安全，这样做即使用户不登录机器，也可以使用。第二，必须要使用多个中间层。从中间层的作用可以看出，它承接了数据库的所有连接，所以，一旦出了问题，就会导致整个系统瘫痪。所以做多个中间层是必要的，这样，如果一个坏了可以登录到另一个。2、实现多据库数据同步
前端连接数据库起均衡作用的有了，下一步的工作是设置构建数据库集群。对于负载均衡，最重要的就是所有服务器的数据都是实时同步的。这是一个集群所必需的，因为，如果数不据实时、不同步，那么用户从一台服务器读出的数据，就有别于从另一台服务器读出的数据，这是不能允许的。所以必须实现数据库的数据同步。这样，在查询的时候就可以有多个资源，实现均衡。
Moebius集群采用将核心程序驻留在每个机器的数据库中的办法，这个核心程序称为Moebius 中间件，主要作用是监测数据库内数据的变化并将变化的数据同步到其他数据库中。数据同步完成后客户端才会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份数据在任何时刻数据的一致性。
正因为Moebius 中间件宿主在数据库中的创新，让中间件不但能知道数据的变化，而且知道引起数据变化的SQL语句，根据SQL语句的类型智能的采取不同的数据同步的策略以保证数据同步成本的最小化。
数据条数很少，数据内容也不大，则直接同步数据
数据条数很少，但是里面包含大数据类型，比如文本，二进制数据等，则先对数据进行压缩然后再同步，从而减少网络带宽的占用和传输所用的时间。
数据条数很多，此时中间件会拿到造成数据变化的SQL语句， 然后对SQL语句进行解析，分析其执行计划和执行成本，并选择是同步数据还是同步SQL语句到其他的数据库中。此种情况应用在对表结构进行调整或者批量更改数据的时候非常有用
--3\Moebius中间件同步策略
数据压缩：
如果需要同步的数据中包含文本、二进制等大数据类型， 则先对数据进行压缩然后再同步，从而减少对网络带宽的消耗和数据在传输过程中所用的时间。尤其对于网络带宽资源非常稀缺的场景。 通过fire_compression_bytes参数进行阀值控制。
批量执行重复性数据：
如果需要同步的数据中包含重复性的数据，则中间件会把重复性的数据合并到一个同步命令中只执行一次，从而减少执行的次数。
例如：执行语句 UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE LastLoginDate < '2008-08-08' 共修改了600条数据，这600条数据的DeleteFlag列具有相同的值，中间件会把这些相同的值合并到一个同步命令中去，同步的SQL语句为：UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID IN(1, 3, 4, 5, 7, 10, 13, 15, ......, 895, 897, 899, 1000)。而不是逐条的去同步：
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 1
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 3
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 4
.
.
.
.
.
.
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 899
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID = 1000
该策略对数据进行批量更新、批量删除的场景下非常有用。 通过rows_in_command参数进行阀值控制。
升级数据库锁（锁优化器）
如果更新的数据量非常大，SQL Server本身会对锁进行升级，将大量较细粒度的锁（例如行）转换为少量较粗粒度的锁（例如表）从而减少系统开销。中间件在同步之前先检查当前SQL Server的锁的粒度，如果锁已经升级，则中间件先对目标数据库直接进行锁升级然后再同步数据。从而避免了目标数据库锁升级的过程。通过fire_lock_optimizer_rows 参数进行阀值控制。 同步SQL语句（同步优化器）
如果更新的数据量非常大，超过了设定的阀值，同步大量的数据势必会消耗大量的网络带宽并且延长同步的时间，甚至会造成网络拥堵。这时候中间件首先获取导致数据变化的SQL语句，分析该SQL语句的类型以及执行成本，并选择是把变化的数据同步过去还是把导致数据变化的SQL语句同步过去。该策略在对表结构进行调整或批量更改数据的时候非常有用，大量的减少网络带宽的消耗，降低同步时间。通过fire_sync_optimizer_rows 参数进行阀值控制。 并发执行SQL语句
即使使用了同步SQL语句策略，总的执行时间也相当于执行两次SQL语句的时间。如果这个时间还是不能接受。可以通过中间件提供的系统存储过程usp_MBS_ParallelExecute在集群中的各个节点数据库中并发执行SQL语句，使执行时间降低到相当于在单机数据库中执行一次的时间。但是要注意并不是所有的语句都适合并发执行，具体请参见usp_MBS_ParallelExecute。
4、透明性
中间件宿主在SQL Server数据库中，这是Moebius 的一个创新，主要是确保原有的数据库架构移植到集群架构上简单方便，避免对系统进行较大的改造。
对开发透明：
中间件是在数据库内部工作的，不改变SQL Server原来的应用特性，开发人员面对的还是熟悉的SQL Server数据库、SQL语句以及开发/调试工具。不需要改变原有的习惯,不需要学习新的工具。
许多关键的数据库技术比如事务、连接池、锁、数据存储、安全等还是依靠SQL Server数据库来完成，对客户来说，无论是研发成本还是实施风险都降到最低。
对管理透明：
对于管理人员来说，仍然可以使用SQL Server提供的管理工具来管理数据库，可以把集群看成一个数据库来管理，系统进行了封装，感觉和使用原来的一个数据库时候一样，易用性非常好。
对应用透明：
对于应用程序的连接，用户只需要在应用程序连接组件中进行配置，将应用程序与数据库集群连接即可，对您的应用程序及业务没有丝毫影响。
引用163