格瑞趋势（Green Trend）是一家专注于数据库集群领域的行业解决方案供应商，致力于数据库的负载均衡集群及分布式数据库集群技术的研发和推广。基于Microsoft SQL Server的内核，研发出了Moebius（莫比斯）系列集群系统，解决了困扰在广大SQL Server用户心头的两大难题： 如何构建数据库的负载均衡集群？ 如何解决数据库高性能、高可伸缩性与低价格之间的矛盾？
问
您的应用系统是否正在使用SQL Server数据库？
您的客户是不是总在抱怨页面结果反馈的非常慢，一些操作的实时性得不到保障？
您的SQL Server系统的负载是不是总是维持在一个非常高的状态下？
您是不是还在为数据库的扩展而发愁呢？
答
Microsoft不是提供了集群（MSCS）吗？难道不能解决这些问题吗？和Moebius for SQL Server负载均衡集群有什么区别？Microsoft SQL Cluster Server、SQL2005镜像、或第三方的HA(高可用性)集群都是单纯的解决高可用性的，不能实现负载均衡。
数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；
因为始终只有一个节点在运行，在性能上得不到提升，系统也就不具备扩展能力；
当现有机器的性能不能满足应用的负载时，只能更换更高配置的机器。
问
既然是这样，那么有没有一个集群既可以实现并行计算达到数据库的高性能，又可以保证数据库的高可用呢？能不能用低成本实现集群的持续扩展呢？
Moebius集群将会把您带入一个全新的负载均衡集群世界, 您将以最小的源代码改动，获得SQL server系统的高效运转。
Moebius for SQLServer负载均衡集群是由一组相互独立的服务器组成，通过中间件相互协作形成一个统一的整体，由多个机器共同支撑业务，实现数据库的高性能。
Moebius for SQLServer负载均衡集群支持无共享磁盘架构，集群中各机器可以不连接一个共享的设备，数据可以存储在每个机器自己的存储介质中,这样冗余的硬件架构不但可以避免单点故障而且提供了杰出的故障恢复能力。一旦发生系统失败，Moebius for SQLServer负载均衡集群对用户保证最高的可用性，保障关键业务数据不丢失。由Moebius构建的集群中，需要更高数据库处理速度时，只需简单地增加数据库服务器就可以实现。这样可以大大减小硬件投资的风险，而且大大提高现有服务的质量，扩展非常方便。 www.grqsh.com
问
您的应用系统是否正在使用SQL Server数据库？
您的客户是不是总在抱怨页面结果反馈的非常慢，一些操作的实时性得不到保障？
您的SQL Server系统的负载是不是总是维持在一个非常高的状态下？
您是不是还在为数据库的扩展而发愁呢？
答
Microsoft不是提供了集群（MSCS）吗？难道不能解决这些问题吗？和Moebius for SQL Server负载均衡集群有什么区别？Microsoft SQL Cluster Server、SQL2005镜像、或第三方的HA(高可用性)集群都是单纯的解决高可用性的，不能实现负载均衡。
数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；
因为始终只有一个节点在运行，在性能上得不到提升，系统也就不具备扩展能力；
当现有机器的性能不能满足应用的负载时，只能更换更高配置的机器。
问
既然是这样，那么有没有一个集群既可以实现并行计算达到数据库的高性能，又可以保证数据库的高可用呢？能不能用低成本实现集群的持续扩展呢？
Moebius集群将会把您带入一个全新的负载均衡集群世界, 您将以最小的源代码改动，获得SQL server系统的高效运转。
Moebius for SQLServer负载均衡集群是由一组相互独立的服务器组成，通过中间件相互协作形成一个统一的整体，由多个机器共同支撑业务，实现数据库的高性能。
Moebius for SQLServer负载均衡集群支持无共享磁盘架构，集群中各机器可以不连接一个共享的设备，数据可以存储在每个机器自己的存储介质中,这样冗余的硬件架构不但可以避免单点故障而且提供了杰出的故障恢复能力。一旦发生系统失败，Moebius for SQLServer负载均衡集群对用户保证最高的可用性，保障关键业务数据不丢失。由Moebius构建的集群中，需要更高数据库处理速度时，只需简单地增加数据库服务器就可以实现。这样可以大大减小硬件投资的风险，而且大大提高现有服务的质量，扩展非常方便。 www.grqsh.com
试问楼主:
1.群集共同运行业务,你的中间件是如何工作的?
2.如果A,B,C共同运行群集业务,假设某一个表放在A服务器上,但这个A服务器出现故障了,你如何保证关键业务数据不丢失?
但是所有的应用都是有条件的,这又不是万能的,肯定是适合一部分场合的,不可能全部包含,伟大的oracle的"RAC"难道没有这样的问题
因为大多数的应用是读多写少,主要目的就是为了解决读带来的压力.
希望大家提出宝贵的意见和建议,尽管这个团队做了很细致的考虑,也尽管团队里有在Microsoft工作过的,难免有不周到的.
多多批评指正,希望大家支持国产,支持新技术.
总不可能修改了SQL Server的源代码吧？
msn:[email protected]
数据库负载均衡是有由Moebius集群的架构来支撑的，集群中的每个节点都具有等同地位，具有相同的数据库，实现了真正的冗余，应用程序连接组件中提供了数据库连接的负载均衡分担功能，可以有效的均衡所有的连接请求，实现了集群中各服务器负载的均衡，进而显著提升数据库系统的性能。
1如何保证各节点数据的一致性，实现数据实时同步？
中间件驻留在每个机器的数据库中，监测数据库内数据的变化并将变化的数据同步到其他数据库中。数据同步完成后客户端才会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份数据在任何时刻数据的一致性。 正因为中间件宿主在数据库中的创新，让中间件不但能知道数据的变化，而且知道引起数据变化的SQL语句，根据SQL语句的类型智能的采取不同的数据同步的策略以保证数据同步成本的最小化。
数据条数很少，数据内容也不大，则直接同步数据
数据条数很少，但是里面包含大数据类型，比如文本，二进制数据等，则先对数据进行压缩然后再同步，从而减少网络带宽的占用和传输所用的时间。
数据条数很多，此时中间件会拿到造成数据变化的SQL语句， 然后对SQL语句进行解析，分析其执行计划和执行成本，并选择是同步数据还是同步SQL语句到其他的数据库中。此种情况应用在对表结构进行调整或者批量更改数据的时候非常有用。
1、上这个解决方案对我已有的应用会产生多大的影响？
2、写是有消耗的，消耗到底有多大， 有没有过测试数据？
3、我非常关心同步的策略及其正确性，有没有更详尽的资料？
希望搂主能够解答：[email protected]
1、对已有系统的影响就是需要把过去的数据导入到集群中，不需要改变应用程序。
2、对于全部是写操作，和SQL 2005mirror相比要略小
如果需要同步的数据中包含文本、二进制等大数据类型， 则先对数据进行压缩然后再同步，从而减少对网络带宽的消耗和数据在传输过程中所用的时间。尤其对于网络带宽资源非常稀缺的场景。 通过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。
数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；
因为始终只有一个节点在运行，在性能上得不到提升，系统也就不具备扩展能力；
当现有机器的性能不能满足应用的负载时，只能更换更高配置的机器。
看来这位朋友对中间件技术比较专业，我在这里略微解释一下moebius中间件，可以理解为我们开发的一段代码，是写在每个节点的数据库里面的，主要是用来同步这些变化的数据的。
出差刚回来，谢谢machao1982的反馈，节后将会发布一个新版本 ,还请多多提出宝贵意见。 确切地说是在我们的研发团里面有在微软工作过的人，至于具体信息我就不能透露了，见谅:)
期待SQL server RAC 很久很久了，
在ITPUB见过介绍，支持技术创新。
有技术和打广告是两码事吧。 微软、IBM等在CSDN上还有很多写手呢， 你的意思是他们也“相当不可靠”了呗:)
如果需要同步的数据中包含重复性的数据，则中间件会把重复性的数据合并到一个同步命令中只执行一次，从而减少执行的次数。
例如：执行语句 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 LastLoginDate < '2008-08-08' 本身不就是一个命令吗，
为什么还要转化为
UPDATE dbo.UserInfo SET DeleteFlag = 1 WHERE UserID IN(1, 3, 4, 5, 7, 10, 13, 15, ......, 895, 897, 899, 1000)呢。这个转化过程是需要消耗很多资源的。还浪费时间。
如果更新的数据量非常大，SQL Server本身会对锁进行升级，将大量较细粒度的锁（例如行）转换为少量较粗粒度的锁（例如表）从而减少系统开销。中间件在同步之前先检查当前SQL Server的锁的粒度，如果锁已经升级，则中间件先对目标数据库直接进行锁升级然后再同步数据。从而避免了目标数据库锁升级的过程。通过fire_lock_optimizer_rows 参数进行阀值控制。 对这个也很纳闷啊。
假如两个数据库服务器A 和B ，用户在A服务器上更新了大量数据，假设更新需要1个小时吧，如果锁的粒度小的话，用户还可以在B服务器上操作该表的其他行，但是如果转换为少量较粗粒度的锁，A和B服务器上整个表将将会在1个小时里，不能被访问。当然我说1个小时有点夸张，但是用户响应时间是很小的，多余3秒钟，就是响应慢。
工作原理
数据库负载均衡是有由Moebius集群的架构来支撑的，集群中的每个节点都具有等同地位，具有相同的数据库，实现了真正的冗余，应用程序连接组件中提供了数据库连接的负载均衡分担功能，可以有效的均衡所有的连接请求，实现了集群中各服务器负载的均衡，进而显著提升数据库系统的性能。
1如何保证各节点数据的一致性，实现数据实时同步？
中间件驻留在每个机器的数据库中，监测数据库内数据的变化并将变化的数据同步到其他数据库中。数据同步完成后客户端才会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份数据在任何时刻数据的一致性。 正因为中间件宿主在数据库中的创新，让中间件不但能知道数据的变化，而且知道引起数据变化的SQL语句，根据SQL语句的类型智能的采取不同的数据同步的策略以保证数据同步成本的最小化。
数据条数很少，数据内容也不大，则直接同步数据
数据条数很少，但是里面包含大数据类型，比如文本，二进制数据等，则先对数据进行压缩然后再同步，从而减少网络带宽的占用和传输所用的时间。
数据条数很多，此时中间件会拿到造成数据变化的SQL语句， 然后对SQL语句进行解析，分析其执行计划和执行成本，并选择是同步数据还是同步SQL语句到其他的数据库中。此种情况应用在对表结构进行调整或者批量更改数据的时候非常有用。 --->
其中有一点 数据同步完成后客户端才会得到响应 部署在广域网上同步对性能的影响有多大，有相关的测试数据吗？
1.采用中间件后，如何保持不同站点的事务一致性？
2.对全局死锁是如何解决的，比如:用户A先对T1表的某一行进行更新，B用户对T2表的某一行进行更新；A用户对T2表的相同行进行更新；B用户对T1的相同行进行更新。这样就形成了全局死锁，如何检测？如何处理？
别的不说了
LB最主要的问题在于锁和Cache
请解释如何防止健忘，脑列和锁资源竞争？
你们这种应用，低端OLTP写事务频繁，你这种降低效率
高端OLAP读可以，不过数据同步上那几根网线可不顶用。因为很简单你不是Share Memory，你是Share all disk data。
和Oracle RAC差了好几个世纪。