数据库集群原理

   对于应用服务器集群，应该是非常常见的。通过集群，可以很简单地通过乘法的方式将服务能力扩大（而且这种扩充的成本要远低于垂直扩充，你只要比较一下一个满配4CPU的PC服务器与2台满配2CPU的服务器的价格就知道了），并且，可以提供系统的高可用性，当一台服务器出现问题时，可以由其他服务器提供服务，避免了服务的中断。

　而对于数据库服务器，集群就比较少见了，以往只用于高端系统，比如象ORACLE就提供了并行模块。

　而ICX的出现，则为SQL SERVER数据库的集群提供了良好的解决方案。（参见：ICX-实现SQL SERVER数据库集群）。

 　我们先看一下这种产品的原理：

　数据库服务器的集群，之所以比应用服务器复杂，是因为数据库要有一个同步的问题，在两边不仅要读，更有一个写的数据如何一致的问题。如果依靠数据库本身的同步，则效率很低，很难以事务级的方式进行（即同步成功才向前端报告事务完成）。

　而ICX的原理，则是象一个路由器一样（所以称为数据库路由器），对服务请求进行分发，如果是查询，则象应用服务器那样，分发到某一台数据库服务器，而如果是更新的请求（包括新增、修改、删除等各类），则同时发送到两边的服务器，并且在两边的更新均完成后才报告事务完成。

　下面分析一下ICX的性能问题：

　首先是提交时的性能，查询是没关系了，因为路由器式的分发相对于查询操作本身时间是很短的，主要要关注的是更新操作。但相对于依靠数据库或文件系统的同步方式而言，ICX的更新是在两边同时进行的，而其他方式是采用A更新-同步-B更新的方式，要做三步工作，所以ICX的效率远高于其他同步方式，可以说其时间基本上就是两台服务器中较慢的一台的时间。（而且注意由于做了负载均衡，这台的速度要比只有一台服务器时还要快）

　其次是整体的并发处理能力，我们以两台服务器为例。如果只有查询，应该基本上可以处理２倍的并发量。但与应用服务器不同的是，更新的操作是在两边同步进行的。因此，并发能力的提升，实际与更新／查询的比例、复杂程度是相关的，如果更新多、查询少，处理能力的提升相对就小一些。但是，常识上数据库应用查询的比例远大于更新，而且查询的复杂度、占用服务器资源也远大于更新（比如更新经常是单表的，基于索引的，而查询中多表联接、多个条件之类的非常常见），所以，可以大致认为提供1.5-1.8倍左右的处理能力。当然，这个只是个很粗的估计。

　另外一点是关于速度的提升。相对于并发而言，对速度的提升相对有限，因为在每台机器上都是对整个数据库进行操作。但是，如果一个数据库服务器的负载少了将近一半，其速度也是可能会有一个明显的提升的。

　至于在数据库路由器进行路由分配时的时间与资源消耗，是很小的，可以忽略不计。除非你是做数量极大的特别简单的数据库操作。