数据库水平切分的实现原理解析

第1章  引言

随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（Java应用为例）：JDBC层的封装，ORM框架层的实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶段（beta版），其运行效率和生产时效性有待考究。就ORM框架层的实现而言，比如Taobao的基于ibatis和Spring的的分布式数据访问层，已有多年的应用，运行效率和生产实效性得到了开发人员和用户的肯定。本文就是以ORM框架层为基础而实现的分布式数据访问层。本课题的难点在于分库后，路由规则的制定和选择以及后期的扩展性，比如：如何做到用最少的数据迁移量，达到扩充数据库容量（增加机器节点）的目的。核心问题将围绕数据库分库分表的路由规则和负载均衡策略展开。

第2章 基本原理和概念

2.1基本原理：

人类认知问题的过程总是这样的：what（什么）-why(为什么)-how(怎么
做)，接下来，本文将就这三个问题展开讨论和研究：

2.1.1什么是数据切分

"Shard" 这个词英文的意思是"碎片"，而作为数据库相关的技术用语，似乎最早见于大型多人在线角色扮演游戏中。"Sharding" 姑且称之为"分片"。Sharding 不是一门新技术，而是一个相对简朴的软件理念。众所周知，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢? 答案是：Sharding。  Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
通过一系列的切分规则将数据水平分布到不同的DB或table中，在通过相应的DB路由或者table路由规则找到需要查询的具体的DB或者table，以进行Query操作。这里所说的“sharding”通常是指“水平切分”，这也是本文讨论的重点。具体将有什么样的切分方式呢和路由方式呢？行文至此，读者难免有所疑问，接下来举个简单的例子：我们针对一个Blog应用中的日志来说明， 比如日志文章（article）表有如下字段：



面对这样的一个表，我们怎样切分呢？怎样将这样的数据分布到不同的数据库中的表中去呢？其实分析blog的应用，我们不难得出这样的结论：blog的应用中，用户分为两种：浏览者和blog的主人。浏览者浏览某个blog，实际上是在一个特定的用户的blog下进行浏览的，而blog的主人管理自己的blog，也同样是在特定的用户blog下进行操作的（在自己的空间下）。所谓的特定的用户，用数据库的字段表示就是“user_id”。就是这个“user_id”，它就是我们需要的分库的依据和规则的基础。我们可以这样做，将user_id为1～10000的所有的文章信息放入DB1中的article表中，将user_id为10001～20000的所有文章信息放入DB2中的article表中，以此类推，一直到DBn。这样一来，文章数据就很自然的被分到了各个数据库中，达到了数据切分的目的。接下来要解决的问题就是怎样找到具体的数据库呢？其实问题也是简单明显的，既然分库的时候我们用到了区分字段user_id，那么很自然，数据库路由的过程当然还是少不了user_id的。考虑一下我们刚才呈现的blog应用，不管是访问别人的blog还是管理自己的blog，总之我都要知道这个blog的用户是谁吧，也就是我们知道了这个blog的user_id，就利用这个user_id，利用分库时候的规则，反过来定位具体的数据库，比如user_id是234，利用该才的规则，就应该定位到DB1，假如user_id是12343，利用该才的规则，就应该定位到DB2。以此类推，利用分库的规则，反向的路由到具体的DB，这个过程我们称之为“DB路由”。
当然考虑到数据切分的DB设计必然是非常规，不正统的DB设计。那么什么样的DB设计是正统的DB设计呢？
我们平常规规矩矩用的基本都是。平常我们会自觉的按照范式来设计我们的数据库，负载高点可能考虑使用相关的Replication机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的（下文会提及）。上面提到的“自觉的按照范式设计”。考虑到数据切分的DB设计，将违背这个通常的规矩和约束，为了切分，我们不得不在数据库的表中出现冗余字段，用作区分字段或者叫做分库的标记字段，比如上面的article的例子中的user_id这样的字段（当然，刚才的例子并没有很好的体现出user_id的冗余性，因为user_id这个字段即使就是不分库，也是要出现的，算是我们捡了便宜吧）。当然冗余字段的出现并不只是在分库的场景下才出现的，在很多大型应用中，冗余也是必须的，这个涉及到高效DB的设计，本文不再赘述。

2.1.2为什么要数据切分

上面对什么是数据切分做了个概要的描述和解释，读者可能会疑问，为什么需要数据切分呢？像Oracle这样成熟稳定的数据库，足以支撑海量数据的存储与查询了？为什么还需要数据切片呢？的确，Oracle的DB确实很成熟很稳定，但是高昂的使用费用和高端的硬件支撑不是每一个公司能支付的起的。试想一下一年几千万的使用费用和动辄上千万元的小型机作为硬件支撑，这是一般公司能支付的起的吗？即使就是能支付的起，假如有更好的方案，有更廉价且水平扩展性能更好的方案，我们为什么不选择呢？
但是，事情总是不尽人意。平常我们会自觉的按照范式来设计我们的数据库，负载高点可能考虑使用相关的Replication机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的。首先它的有效很依赖于读操作的比例，Master往往会成为瓶颈所在，写操作需要顺序排队来执行，过载的话Master首先扛不住，Slaves的数据同步的延迟也可能比较大，而且会大大耗费CPU的计算能力，因为write操作在Master上执行以后还是需要在每台slave机器上都跑一次。这时候 Sharding可能会成为鸡肋了。 Replication搞不定，那么为什么Sharding可以工作呢？道理很简单，因为它可以很好的扩展。我们知道每台机器无论配置多么好它都有自身的物理上限，所以当我们应用已经能触及或远远超出单台机器的某个上限的时候，我们惟有寻找别的机器的帮助或者继续升级的我们的硬件，但常见的方案还是横向扩展, 通过添加更多的机器来共同承担压力。我们还得考虑当我们的业务逻辑不断增长，我们的机器能不能通过线性增长就能满足需求？Sharding可以轻松的将计算，存储，I/O并行分发到多台机器上，这样可以充分利用多台机器各种处理能力，同时可以避免单点失败，提供系统的可用性，进行很好的错误隔离。
综合以上因素，数据切分是很有必要的，且我们在此讨论的数据切分也是将MySql作为背景的。基于成本的考虑，很多公司也选择了Free且Open的MySql。对MySql有所了解的开发人员可能会知道，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢? 答案也是Sharding，也就是我们所说的数据切分方案。
    我们用免费的MySQL和廉价的Server甚至是PC做集群，达到小型机+大型商业DB的效果，减少大量的资金投入，降低运营成本，何乐而不为呢？所以，我们选择Sharding，拥抱Sharding。

2.1.3怎么做到数据切分

说到数据切分，再次我们讲对数据切分的方法和形式进行比较详细的阐述和说明。
数据切分可以是物理上的，对数据通过一系列的切分规则将数据分布到不同的DB服务器上，通过路由规则路由访问特定的数据库，这样一来每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。
数据切分也可以是数据库内的，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表，这样做的目的其实也是很简单的。举个例子说明，比如article表中现在有5000w条数据，此时我们需要在这个表中增加（insert）一条新的数据，insert完毕后，数据库会针对这张表重新建立索引，5000w行数据建立索引的系统开销还是不容忽视的。但是反过来，假如我们将这个表分成100个table呢，从article_001一直到article_100，5000w行数据平均下来，每个子表里边就只有50万行数据，这时候我们向一张只有50w行数据的table中insert数据后建立索引的时间就会呈数量级的下降，极大了提高了DB的运行时效率，提高了DB的并发量。当然分表的好处还不知这些，还有诸如写操作的锁操作等，都会带来很多显然的好处。
综上，分库降低了单点机器的负载；分表，提高了数据操作的效率，尤其是Write操作的效率。行文至此我们依然没有涉及到如何切分的问题。接下来，我们将对切分规则进行详尽的阐述和说明。
上文中提到，要想做到数据的水平切分，在每一个表中都要有相冗余字符作为切分依据和标记字段，通常的应用中我们选用user_id作为区分字段，基于此就有如下三种分库的方式和规则：（当然还可以有其他的方式）
按号段分：
(1) user_id为区分，1～1000的对应DB1，1001～2000的对应DB2，以此类推；
优点：可部分迁移
缺点：数据分布不均

(2)hash取模分：
对user_id进行hash（或者如果user_id是数值型的话直接使用user_id的值也可），然后用一个特定的数字，比如应用中需要将一个数据库切分成4个数据库的话，我们就用4这个数字对user_id的hash值进行取模运算，也就是user_id%4,这样的话每次运算就有四种可能：结果为1的时候对应DB1；结果为2的时候对应DB2；结果为3的时候对应DB3；结果为0的时候对应DB4，这样一来就非常均匀的将数据分配到4个DB中。
优点：数据分布均匀
缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据
(3)在认证库中保存数据库配置
就是建立一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的DB信息，然后才能进行我们需要的查询操作。
优点：灵活性强，一对一关系
缺点：每次查询之前都要多一次查询，性能大打折扣
以上就是通常的开发中我们选择的三种方式，有些复杂的项目中可能会混合使用这三种方式。通过上面的描述，我们对分库的规则也有了简单的认识和了解。当然还会有更好更完善的分库方式，还需要我们不断的探索和发现。

第3章 本课题研究的基本轮廓

上面的文字，我们按照人类认知事物的规律，whatwhyhow这样的方式阐述了数据库切分的一些概念和意义以及对一些常规的切分规则做了概要的介绍。本课题所讨论的分布数据层并不仅仅如此，它是一个完整的数据层解决方案，它到底是什么样的呢？接下来的文字，我将详细阐述本研究课题的完整思想和实现方式。
分布式数据方案提供功能如下：
（1）提供分库规则和路由规则（RouteRule简称RR），将上面的说明中提到的三中切分规则直接内嵌入本系统，具体的嵌入方式在接下来的内容中进行详细的说明和论述；
（2）引入集群（Group）的概念，保证数据的高可用性；
（3）引入负载均衡策略（LoadBalancePolicy简称LB）；
（4）引入集群节点可用性探测机制，对单点机器的可用性进行定时的侦测，以保证LB策略的正确实施，以确保系统的高度稳定性；
（5）引入读/写分离，提高数据的查询速度；
仅仅是分库分表的数据层设计也是不够完善的，当某个节点上的DB服务器出现了宕机的情况的时候，会是什么样的呢？是的，我们采用了数据库切分方案，也就是说有N太机器组成了一个完整的DB，如果有一台机器宕机的话，也仅仅是一个DB的N分之一的数据不能访问而已，这是我们能接受的，起码比切分之前的情况好很多了，总不至于整个DB都不能访问。一般的应用中，这样的机器故障导致的数据无法访问是可以接受的，假设我们的系统是一个高并发的电子商务网站呢？单节点机器宕机带来的经济损失是非常严重的。也就是说，现在我们这样的方案还是存在问题的，容错性能是经不起考验的。当然了，问题总是有解决方案的。我们引入集群的概念，在此我称之为Group，也就是每一个分库的节点我们引入多台机器，每台机器保存的数据是一样的，一般情况下这多台机器分摊负载，当出现宕机情况，负载均衡器将分配负载给这台宕机的机器。这样一来，
就解决了容错性的问题。所以我们引入了集群的概念，并将其内嵌入我们的框架中，成为框架的一部分。



如上图所示，整个数据层有Group1，Group2，Group3三个集群组成，这三个集群就是数据水平切分的结果，当然这三个集群也就组成了一个包含完整数据的DB。每一个Group包括1个Master（当然Master也可以是多个）和N个Slave，这些Master和Slave的数据是一致的。 比如Group1中的一个slave发生了宕机现象，那么还有两个slave是可以用的，这样的模型总是不会造成某部分数据不能访问的问题，除非整个Group里的机器全部宕掉，但是考虑到这样的事情发生的概率非常小（除非是断电了，否则不易发生吧）。
在没有引入集群以前，我们的一次查询的过程大致如下：请求数据层，并传递必要的分库区分字段（通常情况下是user_id）数据层根据区分字段Route到具体的DB在这个确定的DB内进行数据操作。这是没有引入集群的情况，当时引入集群会是什么样子的呢？看图一即可得知，我们的路由器上规则和策略其实只能路由到具体的Group，也就是只能路由到一个虚拟的Group，这个Group并不是某个特定的物理服务器。接下来需要做的工作就是找到具体的物理的DB服务器，以进行具体的数据操作。基于这个环节的需求，我们引入了负载均衡器的概念（LB）。负载均衡器的职责就是定位到一台具体的DB服务器。具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强的操作的话，直接将查询负载分到Master，如果是读操作则通过负载均衡策略分配一个Slave。我们的负载均衡器的主要研究放向也就是负载分发策略，通常情况下负载均衡包括随机负载均衡和加权负载均衡。随机负载均衡很好理解，就是从N个Slave中随机选取一个Slave。这样的随机负载均衡是不考虑机器性能的，它默认为每台机器的性能是一样的。假如真实的情况是这样的，这样做也是无可厚非的。假如实际情况并非如此呢？每个Slave的机器物理性能和配置不一样的情况，再使用随机的不考虑性能的负载均衡，是非常不科学的，这样一来会给机器性能差的机器带来不必要的高负载，甚至带来宕机的危险，同时高性能的数据库服务器也不能充分发挥其物理性能。基于此考虑从，我们引入了加权负载均衡，也就是在我们的系统内部通过一定的接口，可以给每台DB服务器分配一个权值，然后再运行时LB根据权值在集群中的比重，分配一定比例的负载给该DB服务器。当然这样的概念的引入，无疑增大了系统的复杂性和可维护性。有得必有失，我们也没有办法逃过的。
有了分库，有了集群，有了负载均衡器，是不是就万事大吉了呢？事情远没有我们想象的那么简单。虽然有了这些东西，基本上能保证我们的数据层可以承受很大的压力，但是这样的设计并不能完全规避数据库宕机的危害。假如Group1中的slave2宕机了，那么系统的LB并不能得知，这样的话其实是很危险的，因为LB不知道，它还会以为slave2为可用状态，所以还是会给slave2分配负载。这样一来，问题就出来了，客户端很自然的就会发生数据操作失败的错误或者异常。这样是非常不友好的！怎样解决这样的问题呢？我们引入集群节点的可用性探测机制，或者是可用性的数据推送机制。这两种机制有什么不同呢？首先说探测机制吧，顾名思义，探测即使，就是我的数据层客户端，不定时对集群中各个数据库进行可用性的尝试，实现原理就是尝试性链接，或者数据库端口的尝试性访问，都可以做到，当然也可以用JDBC尝试性链接，利用Java的Exception机制进行可用性的判断，具体的会在后面的文字中提到。那数据推送机制又是什么呢？其实这个就要放在现实的应用场景中来讨论这个问题了，一般情况下应用的DB数据库宕机的话我相信DBA肯定是知道的，这个时候DBA手动的将数据库的当前状态通过程序的方式推送到客户端，也就是分布式数据层的应用端，这个时候在更新一个本地的DB状态的列表。并告知LB，这个数据库节点不能使用，请不要给它分配负载。一个是主动的监听机制，一个是被动的被告知的机制。两者各有所长。但是都可以达到同样的效果。这样一来刚才假设的问题就不会发生了，即使就是发生了，那么发生的概率也会降到最低。
上面的文字中提到的Master和Slave，我们并没有做太多深入的讲解。如图一所示，一个Group由1个Master和N个Slave组成。为什么这么做呢？其中Master负责写操作的负载，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在10：1左右，也就是说大量的数据操作是集中在读的操作，这也就是为什么我们会有多个Slave的原因。但是为什么要分离读和写呢？熟悉DB的研发人员都知道，写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上，而读操作其其他的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。读写分离也会引入新的问题，比如我的Master上的数据怎样和集群中其他的Slave机器保持数据的同步和一致呢?这个是我们不需要过多的关注的问题，MySql的Proxy机制可以帮助我们做到这点，由于Proxy机制与本课题相关性不是太强，
在这里不做详细介绍。
综上所述，本课题中所研究的分布式数据层的大体功能就是如此。以上是对基本原理的一些讨论和阐述。接下来就系统设计层面，进行深入的剖析和研究。

第4章 系统设计

4.1系统实现层面的选择

在引言部分中提到，该系统的实现层面有两种选择，一种是基于JDBC层面上的选择，一种是基于现有数据持久层框架层面上的选择，比如Hibernate，ibatis。两种层面各有长处，也各有不足之处。基于JDBC层面上的系统实现，系统开发难度和后期的使用难度都将大大提高。大大增加了系统的开发费用和维护费用。本课题的定位是在成型的ibatis持久层框架的基础上进行上层的封装，而不是对ibatis源码的直接修改，这样一来使本系统不会对现有框架有太多的侵入性，从而也增加了使用的灵活性。之所以选择ibatis，原因如下：
（1）ibatis的学习成本非常低，熟练的Java Programmer可在非常的短时间内熟练使用ibatis；
（2）ibatis是轻量级的ORM，只是简单的完成了RO，OR的映射，其查询语句也是通过配置文件sql-map.xml文件在原生sql的层面进行简单的配置，也就是说我们没有引入诸如Hibernate那样的HQL的概念，从而增强了sql的可控性，优秀的DBA可以很好的从sql的层面对sql进行优化，使数据层的应用有很强的可控性。Hibernate虽然很强大，但是由于Hibernate是OR的一个重型封装，且引入HQL的概念，不便于DBA团队对sql语句的控制和性能的调优。
基于以上两点理由，本课题在ORM的产品的选择上选择了易学易用且轻量级的持久层框架ibatis。下面的讨论也都是特定于ibatis的基础上的讨论。


4.2其他开源框架的选择

在一些大型的Java应用中，我们通常会采用Spring这样的开源框架，尤其是IoC（DI）这部分，有效的帮助开发人员管理对象的依赖关系和层次，降低系统各层次之间的实体耦合。Spring的优点和用处我相信这是开发人员众所周知的，在此不再赘述。本课题的数据层也将采用Spring做为IoC（DI）的框架。
4.3系统开发技术和工具介绍
开发语言：Java JDK1.5
集成开发环境：Eclipse 3.3.4
Web环境下测试服务器：JBoss 4.2
构建工具：淘宝自行研发的构建工具Antx（类似于Maven），当然也可以用Maven
依赖的开源Jar：Spring2.0，ibaits，commons-configuration(读取配置文件)，log4j，junit等
第5章 系统分析（待续。。）

评论

90 楼 xnxqs 2009-07-20  

LZ写道：
基于此就有如下三种分库的方式和规则：（当然还可以有其他的方式）
按号段分：
(1) user_id为区分，1～1000的对应DB1，1001～2000的对应DB2，以此类推；
优点：可部分迁移
缺点：数据分布不均

(2)hash取模分：
对user_id进行hash（或者如果user_id是数值型的话直接使用user_id的值也可），然后用一个特定的数字，比如应用中需要将一个数据库切分成4个数据库的话，我们就用4这个数字对user_id的hash值进行取模运算，也就是user_id%4,这样的话每次运算就有四种可能：结果为1的时候对应DB1；结果为2的时候对应DB2；结果为3的时候对应DB3；结果为0的时候对应DB4，这样一来就非常均匀的将数据分配到4个 DB中。
优点：数据分布均匀
缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据
(3)在认证库中保存数据库配置
就是建立一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的DB信息，然后才能进行我们需要的查询操作。
优点：灵活性强，一对一关系
缺点：每次查询之前都要多一次查询，性能大打折扣
以上就是通常的开发中我们选择的三种方式，有些复杂的项目中可能会混合使用这三种方式。通过上面的描述，我们对分库的规则也有了简单的认识和了解。当然还会有更好更完善的分库方式，还需要我们不断的探索和发现。
________________________________________________________________
楼上的大牛很多，只提醒一点不成熟的意见：你的三种方式或其它的实现方式，是不是要考虑一下对代码的侵入是否严重？。
另LZ提到：
数据切分也可以是数据库内的，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表。。。。

你这个不叫设计了，准确的说应该是具体应用的设计方案了吧？？ 不可能人家做个项目用你的框架还要根据你框架的特色做一些特殊的设计吗？个人觉得一个出色的框架最起码有二点要注意的。1.最少侵入。2最少干扰（数据设计）。所以有关“数据切分也可以是数据库内的”这一观点是不是不太可取？说得不对请指正。

89 楼 argan 2009-07-10  

eason007 写道

在脚本层面做这种SQL分析的工作的确是很大的问题，而且涉及到业务逻辑的变动，需要对原有的脚本进行修改。

目前来说，相对好一点的方案就是那个叫阿巴米的变形虫项目了。

amoeba非常优秀，能很透明的解决掉数据拆分的问题，不过最好是在应用一开始就计划好，否则迁移的成本还是非常大的

88 楼 eason007 2009-07-10  

在脚本层面做这种SQL分析的工作的确是很大的问题，而且涉及到业务逻辑的变动，需要对原有的脚本进行修改。

目前来说，相对好一点的方案就是那个叫阿巴米的变形虫项目了。

87 楼 liuchaoyong 2009-07-06  

<div class="quote_title">lishuaibt 写道</div>
<div class="quote_div">
<div class="quote_title">downpour 写道</div>
<div class="quote_div">我最关心的还是查询和统计。 <br><br>按照我的理解，可能需要一个完整的数据访问层，这个数据访问层能够处理jdbc拥有的一切功能。 <br><br>我想请问一下，楼主是如何实现的。</div>
<p> </p>
<p> 目前不支持多表联查，毕竟可能链接的表不再同一个物理节点中，实现起来效率回事个比较大的问题。现在这个ddal依然在起步阶段，还有很多需要改进的地方。希望各位大侠能给点建议!</p>
</div>
<p><br>楼主可以研究下数据仓库，数据挖掘方面的知识，关注淘宝招聘的信息，多少就能知道淘宝用到的技术了，呵呵。请淘宝里的牛人解决下。。</p>

86 楼 diogin 2009-06-30  

实际上我目前就在尝试封装高度分片的分布式数据库，提供给应用层一个统一的仓储API。然而实际上应用层的需求是无穷无尽的，因此不可能覆盖100%的用例，只能提供一些常用的操作的封装。当时曾想过在这个封装层里编译SQL，生成查询计划，然后分发到各个分片节点上查询，最后在封装层里完成归并，这样可以达到最大化的透明度，后来很快就发现这种做法几乎不可行，一个简单的例子就是SNS系统里，查看好友最新日志这么一个需求。看似简单，不就是 friend 与 note两个表 join 一下再 order by 即可？但当一个人的好友数达到几万（开心网上就有好多人达到这个数）时，选择 top 10 条好友日志，在分片上进行手工 join 时就会遇到困难：需要先取出几万个好友id，然后去 note 表里进行几万个 id 的 in 操作，再 order by，这个操作的效率不仅在数据库层面非常低下，在网络传输层面也效率也非常低。如果 order by 的域还涉及 friend 里的某些域，则这种查询几乎不可能在应用层完成。因此这种 DDAL 对我来说只能是“乌托邦”了。另外，《high performance mysql 2nd edition》里也有一段话提到了这个“乌托邦”：

A completely automated, high-performance, transparent way to partition data and
make it look like it lives on a single server would be wonderful, but it doesn’t exist
yet. In the future, MySQL’s NDB Cluster storage engine might be fast and robust
enough to work well for this purpose.

85 楼 firebody 2009-06-30  

liufeng820 写道

firebody 写道

liufeng820 写道

firebody 写道

zhuyx808 写道

其实我不想回复的，不过看上面那么多人讲来讲去就忍不住了，LZ的这篇文章名应该取做：数据库水平切分的实现方法概述，为什么这么讲，LZ一直在数据库切分问题上一直在外围、皮毛上绕而根本没有切进实质重点去讲，没有对一些重点难点问题比如业务统计查询，事务等方面没有做讲解，而是一笔带过，对数据库Master、Slave、group之间如何同步如何保证一致仅仅依靠mysql的Proxy机制……LZ所省略不去讲的东东才是数据库切分的重点难点，解决了这些重点难点，数据库切分就想怎么切就怎么切了

赞同，我提一些我的看法，做架构/产品设计既要有注重“大” 也要注重“小”。
大的我觉得楼主具备了，也很有思路，敏锐。
小的呢，我觉得有所欠缺。 有大缺小，我觉得远远要比有小缺大要危险的多。

做架构、产品设计，思路要灵活、开阔，但是细节问题更要仔细把握，认真分析，权衡再三。

而光看着大气，赶潮流的方案，就热解沸腾的兴奋状思考，激动完毕，一股脑写成实际方案推行，这样的方案十有八九是陷阱方案。

每个方案都有每个方案的利弊，这些东西你的思考里面一定要仔细斟酌分析清楚，并在你的设计里面写得清清楚楚，这样的方案无论是给客户，还是给自己的团队，都才是实在的可行的东西。

很遗憾，我从讨论的帖子来看，避重就轻，光看着优点，对缺点几乎没做啥分析。

所以，少头脑发热，多踏实做事。

说的太好了...人家抛砖引玉来讨论个问题...你们这帮人除了冷嘲热讽外..一点自己的想法都不拿出来...

说的太好了...还好有楼主这样的人..虽然技术一般..头脑发热...但是人家愿意把自己的所学所想分享给大家..

而不是像你这样...冷静优雅的否定别人的想法...而不是说出自己的见解...

这叫什么? 自己想想吧...

或许我说的话有些过分，但是其实我是想给LZ做一些提醒。
我看了他的帖子，一篇接着一篇，都是分析如何针对这个设计做拓展，如何解决这个设计碰到的问题，如何优化这个设计，以及这个设计的优点。

我说这么严厉（泼冷水），其实是想做一个善意的提醒： 别为了设计而设计。

从任何一个点都可以衍生出很多可以思考讨论的东西来，就比如这么一个设计，光是这么一个设计就可以衍生出众多的讨论出来，正如LZ所说的故障检测，性能分析，负载均衡.....

但是，任何东西在你真正做之前先得分析这个东西是出于什么目的，它能够解决什么问题，不能够解决什么问题 。 他对它所适用的场景有何优势，和其他可选方案对比有何优缺点。
我感觉楼主是花了很大力气来做这块工作的，所以需要提醒的就是开头有这个说明。 才能更全面整体的分析自己的方案。
很多情况是，0可以否定1，何来1后面衍生出的2，3，4，5来呢？
就我的感觉而言，做这么大一个方案，如果我是BOSS，至少需要判断这个方案是否和此类相关的成熟产品做过对比分析？ 没有，那么可以丢到垃圾桶里去了。
当然，苛刻一点，我还得加一个前提，做这个设计的团队是否有足够的经验，以前是否一致使用过相关的产品来做过研发，有足够的经验来做对比分析，整体考虑。没有，也可以让这个团队历练历练再说。
设计，有时候真的可以上瘾而疯狂的，嘿嘿，不是吗？

很抱歉前面针对你的话语有了不礼貌的地方...

其实有些东西是很难做到的,特别以楼主一个还在学校的学生.在写毕业论文的时候, 使用了这个题目.

不客气的说, 如果他能有一个完美的解决方案. 那么他现在直接就会被 Oracle , Mircosoft , IBM 等抢走的.

我想.他做不到. 他能做到的是. 提出这样一个问题. 这种问题可能我们多多少少都曾经遇到过.

也尝试解决过.可是我们也失败了. 或者觉得问题过于复杂. 采用别的方法绕了过去.

但是, 他发起了一个课题. 想解决它. 他自己的经验知识可能无法完成这个任务.

但是我们有 goolge . 有 javaeye , 现在不是 20年前那种英雄主义的时代.

而是可以大家共智共力来解决问题.

有你的提醒.我想如果是在一个真正的项目中.那么会让这个项目减少风险.思路清晰的走下去.

而在此时. 楼主需要的仅仅是大家的一些经验和想法. 来帮他完善自己的构思.

您说.不是吗?

明白了，原来LZ在写毕业论文呢，论文论文，用笔写写出来也不错。 算我多嘴。
我还以为他是在给公司团队写方案呢， 学生做这么大的课题，不错，精神可嘉。
可以参考开心农场的架构思考一下，开心农场的架构其实也是专门针对他自己的领域做得特有的设计。
加一些实际的经验性的总结，论文看上去更可信一些，也少掉一些学院派的气氛。

84 楼 zhuyx808 2009-06-30  

作为一个架构方面的文章来说确实是个好文章
但是实际中里面的泥潭不是一般的深，LZ用的是mysql，那如果换一个数据库该怎么办？确实上面有很多地方值得讨论，就这个架构里面的随便一个关键点拿出来讨论都够写上好几篇论文了，我很早就考虑过这种架构，但是迫于原来说的哪些难点（统计，查询，更新，同步，事务，透明……）一直没有得到很好的解决，最后就放弃掉了，我想LZ如果有好的实现不妨拿出一个demo或者解决方案出来，这样才更有实用性，原来写的哪些不是来泼冷水，只是讲讲我的观点，希望能有个好的解决方案

83 楼 442136713 2009-06-29  

好文啊，学到了不少东西

82 楼 repsihWDX 2009-06-29  

sucker 写道

  有实用性，毕竟用mysql和几台工作站或者pc,替换更昂贵的DBMS和硬件，这个还是很划算。
  不过这有几个问题：
     1.同类数据分散在不同表和库中，在做统计时，貌似无法用常规方法得到。不过可以考虑单独做个统计数据，在每次更新表数据时，先在这里更新一次统计数据，以后需要统计数据时，从这里计算。这只是个大概的想法，只能做预先设计好的统计。
     2.事务的管理。小弟对mysql不了解，不知道能否支持跨库的事务。也许在应用程序级中控制事务？每次提交sql都附送一个反向操作sql？或则每张表设置个有效字段？（事务这点也不是一定，不是所有应用都具有事务性。）
     3.最终要的是，sql语句的解析。提供给用户的接口应该是让用户书写标准的sql，后面的分库分表对用户应该都是透明的，而程序需要将标准sql解析后进行跨库跨表的读写。
     小弟的一些愚见，也请楼主和各位指点。

想法还是不错的:)

2.一般来说事务可以通过合理的表结构设计来规避，核心的思想是能不用事务就不用，如果要用事务就把事物关联的表放在一个物理库。其余的通过补偿的机制来完成。

3.是的。不过这东西还是有局限的。

81 楼 sucker 2009-06-29  

  有实用性，毕竟用mysql和几台工作站或者pc,替换更昂贵的DBMS和硬件，这个还是很划算。
  不过这有几个问题：
     1.同类数据分散在不同表和库中，在做统计时，貌似无法用常规方法得到。不过可以考虑单独做个统计数据，在每次更新表数据时，先在这里更新一次统计数据，以后需要统计数据时，从这里计算。这只是个大概的想法，只能做预先设计好的统计。
     2.事务的管理。小弟对mysql不了解，不知道能否支持跨库的事务。也许在应用程序级中控制事务？每次提交sql都附送一个反向操作sql？或则每张表设置个有效字段？（事务这点也不是一定，不是所有应用都具有事务性。）
     3.最终要的是，sql语句的解析。提供给用户的接口应该是让用户书写标准的sql，后面的分库分表对用户应该都是透明的，而程序需要将标准sql解析后进行跨库跨表的读写。
     小弟的一些愚见，也请楼主和各位指点。

80 楼 lishuaibt 2009-06-29  

liufeng820 写道

firebody 写道

liufeng820 写道

firebody 写道

zhuyx808 写道

其实我不想回复的，不过看上面那么多人讲来讲去就忍不住了，LZ的这篇文章名应该取做：数据库水平切分的实现方法概述，为什么这么讲，LZ一直在数据库切分问题上一直在外围、皮毛上绕而根本没有切进实质重点去讲，没有对一些重点难点问题比如业务统计查询，事务等方面没有做讲解，而是一笔带过，对数据库Master、Slave、group之间如何同步如何保证一致仅仅依靠mysql的Proxy机制……LZ所省略不去讲的东东才是数据库切分的重点难点，解决了这些重点难点，数据库切分就想怎么切就怎么切了

赞同，我提一些我的看法，做架构/产品设计既要有注重“大” 也要注重“小”。
大的我觉得楼主具备了，也很有思路，敏锐。
小的呢，我觉得有所欠缺。 有大缺小，我觉得远远要比有小缺大要危险的多。

做架构、产品设计，思路要灵活、开阔，但是细节问题更要仔细把握，认真分析，权衡再三。

而光看着大气，赶潮流的方案，就热解沸腾的兴奋状思考，激动完毕，一股脑写成实际方案推行，这样的方案十有八九是陷阱方案。

每个方案都有每个方案的利弊，这些东西你的思考里面一定要仔细斟酌分析清楚，并在你的设计里面写得清清楚楚，这样的方案无论是给客户，还是给自己的团队，都才是实在的可行的东西。

很遗憾，我从讨论的帖子来看，避重就轻，光看着优点，对缺点几乎没做啥分析。

所以，少头脑发热，多踏实做事。

说的太好了...人家抛砖引玉来讨论个问题...你们这帮人除了冷嘲热讽外..一点自己的想法都不拿出来...

说的太好了...还好有楼主这样的人..虽然技术一般..头脑发热...但是人家愿意把自己的所学所想分享给大家..

而不是像你这样...冷静优雅的否定别人的想法...而不是说出自己的见解...

这叫什么? 自己想想吧...

或许我说的话有些过分，但是其实我是想给LZ做一些提醒。
我看了他的帖子，一篇接着一篇，都是分析如何针对这个设计做拓展，如何解决这个设计碰到的问题，如何优化这个设计，以及这个设计的优点。

我说这么严厉（泼冷水），其实是想做一个善意的提醒： 别为了设计而设计。

从任何一个点都可以衍生出很多可以思考讨论的东西来，就比如这么一个设计，光是这么一个设计就可以衍生出众多的讨论出来，正如LZ所说的故障检测，性能分析，负载均衡.....

但是，任何东西在你真正做之前先得分析这个东西是出于什么目的，它能够解决什么问题，不能够解决什么问题 。 他对它所适用的场景有何优势，和其他可选方案对比有何优缺点。
我感觉楼主是花了很大力气来做这块工作的，所以需要提醒的就是开头有这个说明。 才能更全面整体的分析自己的方案。
很多情况是，0可以否定1，何来1后面衍生出的2，3，4，5来呢？
就我的感觉而言，做这么大一个方案，如果我是BOSS，至少需要判断这个方案是否和此类相关的成熟产品做过对比分析？ 没有，那么可以丢到垃圾桶里去了。
当然，苛刻一点，我还得加一个前提，做这个设计的团队是否有足够的经验，以前是否一致使用过相关的产品来做过研发，有足够的经验来做对比分析，整体考虑。没有，也可以让这个团队历练历练再说。
设计，有时候真的可以上瘾而疯狂的，嘿嘿，不是吗？

很抱歉前面针对你的话语有了不礼貌的地方...

其实有些东西是很难做到的,特别以楼主一个还在学校的学生.在写毕业论文的时候, 使用了这个题目.

不客气的说, 如果他能有一个完美的解决方案. 那么他现在直接就会被 Oracle , Mircosoft , IBM 等抢走的.

我想.他做不到. 他能做到的是. 提出这样一个问题. 这种问题可能我们多多少少都曾经遇到过.

也尝试解决过.可是我们也失败了. 或者觉得问题过于复杂. 采用别的方法绕了过去.

但是, 他发起了一个课题. 想解决它. 他自己的经验知识可能无法完成这个任务.

但是我们有 goolge . 有 javaeye , 现在不是 20年前那种英雄主义的时代.

而是可以大家共智共力来解决问题.

有你的提醒.我想如果是在一个真正的项目中.那么会让这个项目减少风险.思路清晰的走下去.

而在此时. 楼主需要的仅仅是大家的一些经验和想法. 来帮他完善自己的构思.

您说.不是吗?

是的，这个确实是我本科毕业论文的一部分，后面的实现部分还没有写呢。。。

这个论题是我在公司实习期间接触到的，现在也有比较成型的线上产品在运行。最初的设计目标并不打算做成通用的广泛的DDAL。。。而是针对特定技术的解决方案！

79 楼 lishuaibt 2009-06-29  

zhaobin9 写道

长期潜水，不过，看到LZ的文章，还是上来冒个泡：

1、从系统架构分析的角度来说，LZ的文章还是非常棒的，前因后果，清清楚楚。值得鼓励！
2、从技术实现的角度来说，LZ还没有写到那儿呢，慢工出细活啊，只有翘首期待！

另外，想问问LZ，你的设计目标是什么？
是针对淘宝的需求，在Spring + ibatis上做一个可扩展、高可用的数据库水平切分方案？
是否考虑支持Hibernate？是否自动支持跨库事务、二级缓存？（如果只支持ibatis，支持者可就少了一大半呀）

或者干脆考虑做一个DDAL？采用Map Reduce进行分布式计算，直接将数据库切分与程序开发完全隔离，形成全自动的切分方案？并且支持统计等，呵呵，这就爽了。（现在有这样的开源项目吗？这是个很好的思路呀！）

确实是针对Spring+ibatis的一种解决方案，并不打算支持Hibernate。

目前国内有一个叫做变形虫的项目，其实现思想可能又是站在另外一个角度的吧！

78 楼 liufeng820 2009-06-29  

firebody 写道

liufeng820 写道

firebody 写道

zhuyx808 写道

其实我不想回复的，不过看上面那么多人讲来讲去就忍不住了，LZ的这篇文章名应该取做：数据库水平切分的实现方法概述，为什么这么讲，LZ一直在数据库切分问题上一直在外围、皮毛上绕而根本没有切进实质重点去讲，没有对一些重点难点问题比如业务统计查询，事务等方面没有做讲解，而是一笔带过，对数据库Master、Slave、group之间如何同步如何保证一致仅仅依靠mysql的Proxy机制……LZ所省略不去讲的东东才是数据库切分的重点难点，解决了这些重点难点，数据库切分就想怎么切就怎么切了

赞同，我提一些我的看法，做架构/产品设计既要有注重“大” 也要注重“小”。
大的我觉得楼主具备了，也很有思路，敏锐。
小的呢，我觉得有所欠缺。 有大缺小，我觉得远远要比有小缺大要危险的多。

做架构、产品设计，思路要灵活、开阔，但是细节问题更要仔细把握，认真分析，权衡再三。

而光看着大气，赶潮流的方案，就热解沸腾的兴奋状思考，激动完毕，一股脑写成实际方案推行，这样的方案十有八九是陷阱方案。

每个方案都有每个方案的利弊，这些东西你的思考里面一定要仔细斟酌分析清楚，并在你的设计里面写得清清楚楚，这样的方案无论是给客户，还是给自己的团队，都才是实在的可行的东西。

很遗憾，我从讨论的帖子来看，避重就轻，光看着优点，对缺点几乎没做啥分析。

所以，少头脑发热，多踏实做事。

说的太好了...人家抛砖引玉来讨论个问题...你们这帮人除了冷嘲热讽外..一点自己的想法都不拿出来...

说的太好了...还好有楼主这样的人..虽然技术一般..头脑发热...但是人家愿意把自己的所学所想分享给大家..

而不是像你这样...冷静优雅的否定别人的想法...而不是说出自己的见解...

这叫什么? 自己想想吧...

或许我说的话有些过分，但是其实我是想给LZ做一些提醒。
我看了他的帖子，一篇接着一篇，都是分析如何针对这个设计做拓展，如何解决这个设计碰到的问题，如何优化这个设计，以及这个设计的优点。

我说这么严厉（泼冷水），其实是想做一个善意的提醒： 别为了设计而设计。

从任何一个点都可以衍生出很多可以思考讨论的东西来，就比如这么一个设计，光是这么一个设计就可以衍生出众多的讨论出来，正如LZ所说的故障检测，性能分析，负载均衡.....

但是，任何东西在你真正做之前先得分析这个东西是出于什么目的，它能够解决什么问题，不能够解决什么问题 。 他对它所适用的场景有何优势，和其他可选方案对比有何优缺点。
我感觉楼主是花了很大力气来做这块工作的，所以需要提醒的就是开头有这个说明。 才能更全面整体的分析自己的方案。
很多情况是，0可以否定1，何来1后面衍生出的2，3，4，5来呢？
就我的感觉而言，做这么大一个方案，如果我是BOSS，至少需要判断这个方案是否和此类相关的成熟产品做过对比分析？ 没有，那么可以丢到垃圾桶里去了。
当然，苛刻一点，我还得加一个前提，做这个设计的团队是否有足够的经验，以前是否一致使用过相关的产品来做过研发，有足够的经验来做对比分析，整体考虑。没有，也可以让这个团队历练历练再说。
设计，有时候真的可以上瘾而疯狂的，嘿嘿，不是吗？

很抱歉前面针对你的话语有了不礼貌的地方...

其实有些东西是很难做到的,特别以楼主一个还在学校的学生.在写毕业论文的时候, 使用了这个题目.

不客气的说, 如果他能有一个完美的解决方案. 那么他现在直接就会被 Oracle , Mircosoft , IBM 等抢走的.

我想.他做不到. 他能做到的是. 提出这样一个问题. 这种问题可能我们多多少少都曾经遇到过.

也尝试解决过.可是我们也失败了. 或者觉得问题过于复杂. 采用别的方法绕了过去.

但是, 他发起了一个课题. 想解决它. 他自己的经验知识可能无法完成这个任务.

但是我们有 goolge . 有 javaeye , 现在不是 20年前那种英雄主义的时代.

而是可以大家共智共力来解决问题.

有你的提醒.我想如果是在一个真正的项目中.那么会让这个项目减少风险.思路清晰的走下去.

而在此时. 楼主需要的仅仅是大家的一些经验和想法. 来帮他完善自己的构思.

您说.不是吗?

77 楼 matin0728 2009-06-29  

comet12345678 写道

像AGE那样基于文件系统存储，提供类sql的工具，成为分布式数据库了。数据切分对AGE而言是天然的。

可否说明一下这个AGE是个什么东西，或者相关的链接？ 还是第一次看到这个东西...

76 楼 liu0107613 2009-06-29  

不错的文章，其实这些方案都在压力不断增加的情况下，想出的。。。分散压力。首先把多表分算到不同的DB中，然后把数据根据关键列，分布到不同的数据库中。库分布以后，系统的查询，io等操作都可以有多个机器组成的群组共同完成了。。

75 楼 zhaobin9 2009-06-28  

长期潜水，不过，看到LZ的文章，还是上来冒个泡：

1、从系统架构分析的角度来说，LZ的文章还是非常棒的，前因后果，清清楚楚。值得鼓励！
2、从技术实现的角度来说，LZ还没有写到那儿呢，慢工出细活啊，只有翘首期待！

另外，想问问LZ，你的设计目标是什么？
是针对淘宝的需求，在Spring + ibatis上做一个可扩展、高可用的数据库水平切分方案？
是否考虑支持Hibernate？是否自动支持跨库事务、二级缓存？（如果只支持ibatis，支持者可就少了一大半呀）

或者干脆考虑做一个DDAL？采用Map Reduce进行分布式计算，直接将数据库切分与程序开发完全隔离，形成全自动的切分方案？并且支持统计等，呵呵，这就爽了。（现在有这样的开源项目吗？这是个很好的思路呀！）

74 楼 ywbanm 2009-06-28  

大概看了下楼主的文章哈
现在手头正好有个老系统，准备用分库解决性能那个问题

现在遇到的问题更多上是业务逻辑上的，因为是老系统改造嘛

问题：
1，如何引入多数据源？（在最少修改原有DAO的情况下）
2，如果修改原有的存储过程？（不要问为什么用存储过程，老系统就是用了）
3，使用分布式事务会非常影响性能？（比如JTA XAResource，毕竟80%以上的操作还是针对单数据源的）
4，分区后数据如何灵活切换？（比如原来是DB1的，现在我要换到DB2上，可能有一系列的相关数据需要转移）
5，统一的统计查询。（现在是在Web层直接使用多数据源，但是没有办法对Web层隐藏么）

觉得楼主想法说出来了，但是具体如何实施等办法没有说，有点隔靴搔痒啊

73 楼 firebody 2009-06-28  

liufeng820 写道

firebody 写道

zhuyx808 写道

其实我不想回复的，不过看上面那么多人讲来讲去就忍不住了，LZ的这篇文章名应该取做：数据库水平切分的实现方法概述，为什么这么讲，LZ一直在数据库切分问题上一直在外围、皮毛上绕而根本没有切进实质重点去讲，没有对一些重点难点问题比如业务统计查询，事务等方面没有做讲解，而是一笔带过，对数据库Master、Slave、group之间如何同步如何保证一致仅仅依靠mysql的Proxy机制……LZ所省略不去讲的东东才是数据库切分的重点难点，解决了这些重点难点，数据库切分就想怎么切就怎么切了

赞同，我提一些我的看法，做架构/产品设计既要有注重“大” 也要注重“小”。
大的我觉得楼主具备了，也很有思路，敏锐。
小的呢，我觉得有所欠缺。 有大缺小，我觉得远远要比有小缺大要危险的多。

做架构、产品设计，思路要灵活、开阔，但是细节问题更要仔细把握，认真分析，权衡再三。

而光看着大气，赶潮流的方案，就热解沸腾的兴奋状思考，激动完毕，一股脑写成实际方案推行，这样的方案十有八九是陷阱方案。

每个方案都有每个方案的利弊，这些东西你的思考里面一定要仔细斟酌分析清楚，并在你的设计里面写得清清楚楚，这样的方案无论是给客户，还是给自己的团队，都才是实在的可行的东西。

很遗憾，我从讨论的帖子来看，避重就轻，光看着优点，对缺点几乎没做啥分析。

所以，少头脑发热，多踏实做事。

说的太好了...人家抛砖引玉来讨论个问题...你们这帮人除了冷嘲热讽外..一点自己的想法都不拿出来...

说的太好了...还好有楼主这样的人..虽然技术一般..头脑发热...但是人家愿意把自己的所学所想分享给大家..

而不是像你这样...冷静优雅的否定别人的想法...而不是说出自己的见解...

这叫什么? 自己想想吧...

或许我说的话有些过分，但是其实我是想给LZ做一些提醒。
我看了他的帖子，一篇接着一篇，都是分析如何针对这个设计做拓展，如何解决这个设计碰到的问题，如何优化这个设计，以及这个设计的优点。

我说这么严厉（泼冷水），其实是想做一个善意的提醒： 别为了设计而设计。

从任何一个点都可以衍生出很多可以思考讨论的东西来，就比如这么一个设计，光是这么一个设计就可以衍生出众多的讨论出来，正如LZ所说的故障检测，性能分析，负载均衡.....

但是，任何东西在你真正做之前先得分析这个东西是出于什么目的，它能够解决什么问题，不能够解决什么问题 。 他对它所适用的场景有何优势，和其他可选方案对比有何优缺点。
我感觉楼主是花了很大力气来做这块工作的，所以需要提醒的就是开头有这个说明。 才能更全面整体的分析自己的方案。
很多情况是，0可以否定1，何来1后面衍生出的2，3，4，5来呢？
就我的感觉而言，做这么大一个方案，如果我是BOSS，至少需要判断这个方案是否和此类相关的成熟产品做过对比分析？ 没有，那么可以丢到垃圾桶里去了。
当然，苛刻一点，我还得加一个前提，做这个设计的团队是否有足够的经验，以前是否一致使用过相关的产品来做过研发，有足够的经验来做对比分析，整体考虑。没有，也可以让这个团队历练历练再说。
设计，有时候真的可以上瘾而疯狂的，嘿嘿，不是吗？

72 楼 lishuaibt 2009-06-28  

看了大家的回复，各种各样的都有！其实写这篇文章的目的就是想跟大家讨论一下分库宏观思想方面的一些内容。现在看来，讨论的似乎有点偏了。这也是不想看到的结果！楼上几位大侠的回复中提到了这篇文章没有介绍一些实质性的文章，认为这是一时头脑发热的表现，觉得没有实际的东西。。

实际的东西肯定是有的，而且也是在实际的项目中使用的东西，只是由于时间的原因，还没有对具体的实现做分析。。以后有时间了一定分享！希望下面的讨论能回到我们的主题来好不好，希望挑毛病的大侠们能给点真诚的意见或者建议，不要只说不对，请您说一下是哪儿不对，需要怎么做！这样的话，我这个菜鸟才能变成想您一样的大侠，不是吗？

71 楼 碧海山城 2009-06-27  

LS。。是传说中的ZB么？