名词请教！！

建议作为客户对象的定位方法。

负载均衡讲究4个要点：故障转移、故障恢复、可管理、可伸缩，负载均衡的可伸缩需要采用散列方案可动态增加节点才算，目前可伸缩主要有两种模式：一种是global中心表记录客户所在位置，根据节点客户数平均分配，当增加一个节点时会因为该节点客户数较少优先新增到该节点直至平衡；另一种通过控制hash算法参数实现。

目前这种实现模式实现了历史数据散列，在未来发展上随着客户不断增删节点不断增加，如作为负载均衡在伸缩性上有较大限制。

你这种揣测就很没意思
因为他的系统虽然不是免费scale，但成本是线性的
超过三百万用户怎么办？改程序呗。
有这么多用户带来revenue，怕什么？
如果两个月之后又超过四百万，他开心都来不及，改点程序算什么。
你该去了解一下中国化工网的架构
只要用户数与revenue线性相关（并且有足够的margin），你就不用担心线性的scale成本

不知道mysql5.1有了水平分区以后还要这么复杂的解决方案干什么

DBLocator

不用好奇，对于商业项目来说这根本不是什么怪异的设计，我之前的一个WEB项目6KW用户，峰值访问9百万，数据库mysql5，其中就用到了这种水平切分，根据用户ID取模切分到16个DB实例中


至于这种方案的名字没有确定过Router和Dispatcher都不贴切，因为对于java的service层来说，数据库是透明的，前些天看到robbin在某个帖子里面说过google 贡献的shards好像就是干这个用的，楼主可以找找

查到一个资料，叫做“Hibernate Shards”

http://www.hibernate.org/414.html

以前还看到一个InfoQ的报道，关于MySQL Proxy的

http://www.infoq.com/cn/news/2007/10/mysqlproxyrwsplitting

其中也提了一句：“Jan提醒说这个技巧还可以用来实现其他的数据分布策略，例如分片（Sharding）”

似乎这个名词，应该叫“horizontal partitioning  水平分区”，或者叫“Sharding 分片”。

不过我的确比较担心，如果你的查询，需要 Where name like '%xxx%' order by id
该怎么处理，还是根本就不会有这样的查询情况？