2008-02-19
名词请教!!
这个图表示 web server会根据用户的id,从对应的数据库节点去存取。
即:
user id 为 000000-100000范围的,web server到 数据库结点A 去crud(create,read,update,delete)
user id 为 100000-200000范围的,web server到 数据库结点B 去crud
user id 为 200000-300000范围的,web server到 数据库结点C 去crud
XXX具体执行这个判断,今天和朋友讨论这样一个设计的时候,我们对如何称呼XXX产生了分歧,
朋友和我都坚称自己的认为没问题的看法,特此请教下大家的意见:
1、负载均衡器/负载均衡模块
2、路由器/路由模块
3、其它___
评论
庄表伟
2008-03-12
查到一个资料,叫做“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
该怎么处理,还是根本就不会有这样的查询情况?
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
该怎么处理,还是根本就不会有这样的查询情况?
bluemeteor
2008-03-12
C3PO 写道
这种怪异的设计
本公子很好奇你们的系统超过300000个用户之后会有什么表现
本公子很好奇你们的系统超过300000个用户之后会有什么表现
不用好奇,对于商业项目来说这根本不是什么怪异的设计,我之前的一个WEB项目6KW用户,峰值访问9百万,数据库mysql5,其中就用到了这种水平切分,根据用户ID取模切分到16个DB实例中
至于这种方案的名字没有确定过Router和Dispatcher都不贴切,因为对于java的service层来说,数据库是透明的,前些天看到robbin在某个帖子里面说过google 贡献的shards好像就是干这个用的,楼主可以找找
JavaInActoin
2008-03-11
DBLocator
dingyuan
2008-03-11
不知道mysql5.1有了水平分区以后还要这么复杂的解决方案干什么
gigix
2008-02-20
C3PO 写道
这种怪异的设计
本公子很好奇你们的系统超过300000个用户之后会有什么表现
本公子很好奇你们的系统超过300000个用户之后会有什么表现
你这种揣测就很没意思
因为他的系统虽然不是免费scale,但成本是线性的
超过三百万用户怎么办?改程序呗。
有这么多用户带来revenue,怕什么?
如果两个月之后又超过四百万,他开心都来不及,改点程序算什么。
你该去了解一下中国化工网的架构
只要用户数与revenue线性相关(并且有足够的margin),你就不用担心线性的scale成本
diystar
2008-02-20
建议作为客户对象的定位方法。
负载均衡讲究4个要点:故障转移、故障恢复、可管理、可伸缩,负载均衡的可伸缩需要采用散列方案可动态增加节点才算,目前可伸缩主要有两种模式:一种是global中心表记录客户所在位置,根据节点客户数平均分配,当增加一个节点时会因为该节点客户数较少优先新增到该节点直至平衡;另一种通过控制hash算法参数实现。
目前这种实现模式实现了历史数据散列,在未来发展上随着客户不断增删节点不断增加,如作为负载均衡在伸缩性上有较大限制。
负载均衡讲究4个要点:故障转移、故障恢复、可管理、可伸缩,负载均衡的可伸缩需要采用散列方案可动态增加节点才算,目前可伸缩主要有两种模式:一种是global中心表记录客户所在位置,根据节点客户数平均分配,当增加一个节点时会因为该节点客户数较少优先新增到该节点直至平衡;另一种通过控制hash算法参数实现。
目前这种实现模式实现了历史数据散列,在未来发展上随着客户不断增删节点不断增加,如作为负载均衡在伸缩性上有较大限制。
Qieqie
2008-02-20
以下是两个人的观点,供参考:
一、
某大型SNS网站(java-based) Team Leader给的msn回复:
“我们还真没有具体叫过什么名字, 就是将数据作了水平拆分,减少数据库的压力。这么看叫 router 可能更确些。”
二、微软中国 某Team Leader:
嘎嘎风 — BlueScreen 说:
我认为router好点吧
嘎嘎风 — BlueScreen 说:
因为后台的db不等价
一、
某大型SNS网站(java-based) Team Leader给的msn回复:
“我们还真没有具体叫过什么名字, 就是将数据作了水平拆分,减少数据库的压力。这么看叫 router 可能更确些。”
二、微软中国 某Team Leader:
嘎嘎风 — BlueScreen 说:
我认为router好点吧
嘎嘎风 — BlueScreen 说:
因为后台的db不等价
Somerset
2008-02-20
这个不能叫负载均衡,叫userdb dispatcher(用户数据库分配器)比较好
Qieqie
2008-02-20
叶子 写道
weiqingfei 写道
没听说过这种负载均衡方法,根据用户特征来确定目的地,应该是router的功能。
传闻网易是根据用户名的第一个字母来的
有待证实
看应用情况。
如果用户提供的是登录名进入系统,此时就是根据用户名路由,
至于具体hash(logonName),还是logonName.charAt(0),就各自有各自更细的决策了
总之不会根据user id(除非有另外的组件提供了logonName->user id的映射,这样才可以使用user id做range路由)
imjl
2008-02-20
像这样的我一般会称之为 用户访问管理器。
叶子
2008-02-20
weiqingfei 写道
没听说过这种负载均衡方法,根据用户特征来确定目的地,应该是router的功能。
传闻网易是根据用户名的第一个字母来的
有待证实
johnyq
2008-02-19
个人也觉得路由比较贴切。。
ps:传说中腾讯即采用类似的方式,根据QQ号段进行分发处理
ps:传说中腾讯即采用类似的方式,根据QQ号段进行分发处理
weiqingfei
2008-02-19
没听说过这种负载均衡方法,根据用户特征来确定目的地,应该是router的功能。
Feiing
2008-02-19
Router 根据消息内容分发
LoadBalancer 根据 server 负载分发
应该是 Router
LoadBalancer 根据 server 负载分发
应该是 Router
lixigua
2008-02-19
路由似乎比负载均衡器好。
负载均衡是目的,采用路由手段是做事的方法。既然针对模块来的,直接用做事的方法名作为名词好些。
负载均衡是目的,采用路由手段是做事的方法。既然针对模块来的,直接用做事的方法名作为名词好些。
发表评论
提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则
- 浏览: 188249 次
- 性别:

- 来自: 北京

- 详细资料
搜索本博客
最近加入圈子
最新评论
-
使用 庖丁分词(2.0.4-alp ...
请问,啥时候出新版本的paoding分词? 谢谢,等急死了
-- by shguan@toptimetech.com -
使用 庖丁分词(2.0.4-alp ...
支持,测试过庖丁分词比IKAnalyzer感觉要好些
-- by keller -
设计的一个考虑点:区分数 ...
把不变的信息放到缓存里那要多大得内存才够啊,分布式缓存。。 确实成本比较高,那你 ...
-- by bloodrate -
设计的一个考虑点:区分数 ...
taobao是用什么东西去映射这些在不同的服务器上面的数据的呢?
-- by laiseeme -
设计的一个考虑点:区分数 ...
不错的设计,耦合度明显比将两者设计在一起要来得低
-- by jbon






评论排行榜