锁定老帖子 主题:淘宝下单高并发解决方案
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2012-04-27
"也许有的朋友会想到拆分之后对全数据做统计会有问题。如果在拆分后的表上做统计,是肯定会有问题的。怎么做呢?其实很简单,把数据迁移到别的库中去做统计。"
这句话是说会定期把分表甚至分库的数据都合并到若干统计服务器? |
|
返回顶楼 | |
发表时间:2012-04-27
ray_linn 写道 montya 写道 yukaizhao 写道 订单号介绍勘误:
文中对于订单号的表述有点问题,对于16台服务器,每台服务器64张表只需要2位买家或卖家id的后两位数字就可以准确定位到具体的库和表。订单号中同时存在买家id的最后两位和卖家id的最后两位。分别在订单号的倒数第3,4位数和最后两位数。 假定买家id为123456789,那么在订单号中的最后两位就是89,通过89对16取模就可以定位到具体的库上,通过对64取模就可以定位到具体的表上。 简单靠取模来判断数据和表,不太好吧。 如果后期有新表和服务器。加入呢。 用类似memcache 中一致性hash。不知道怎么样。 应该用一致性哈希来保证均匀性。。。 订单号应该类似自增长的自然数,使用取模还是能保证均匀性的. |
|
返回顶楼 | |
发表时间:2012-04-27
不过TFS采用这种方式去避免namenode的访问压力的确是比较不错
|
|
返回顶楼 | |
发表时间:2012-04-28
程序新手 写道 请教一下
1)比如说你拆分了物品表,而这个表按照你说的已经分成了现在你想要对这个物品按照不同的条件进行分别的排序,怎么办? 2)另外如果有业务需求需要连表查询,怎么办? 3)个人觉得你对订单的举例,只是where条件中的一个条件,如果有其他条件怎么办? 同问,比较不理解的是如何实现关联查询。 |
|
返回顶楼 | |
发表时间:2012-04-28
虽然看后不是很了解 但是还是多少有点收获的
|
|
返回顶楼 | |
发表时间:2012-04-28
这些ID本来就散列的. 直接取模就好了.
一致性哈希, 不适合这样的场景. |
|
返回顶楼 | |
发表时间:2012-04-28
三问飞絮 写道 程序新手 写道 请教一下
1)比如说你拆分了物品表,而这个表按照你说的已经分成了现在你想要对这个物品按照不同的条件进行分别的排序,怎么办? 2)另外如果有业务需求需要连表查询,怎么办? 3)个人觉得你对订单的举例,只是where条件中的一个条件,如果有其他条件怎么办? 同问,比较不理解的是如何实现关联查询。 |
|
返回顶楼 | |
发表时间:2012-04-28
再怎么说。。也只是分库分表。。好歹给点怎么封装这些分库分表操作的代码之类的吧
|
|
返回顶楼 | |
发表时间:2012-04-28
JE帐号 写道 "也许有的朋友会想到拆分之后对全数据做统计会有问题。如果在拆分后的表上做统计,是肯定会有问题的。怎么做呢?其实很简单,把数据迁移到别的库中去做统计。"
这句话是说会定期把分表甚至分库的数据都合并到若干统计服务器? 是不是使用数据库的主从复制、读写分离, 也就是统计库的数据会从主库中获取一份备份, 主数据库用于数据的插入和更新操作, 从数据库专门用于数据的读取! |
|
返回顶楼 | |
发表时间:2012-04-28
程序新手 写道 请教一下
1)比如说你拆分了物品表,而这个表按照你说的已经分成了现在你想要对这个物品按照不同的条件进行分别的排序,怎么办? 2)另外如果有业务需求需要连表查询,怎么办? 3)个人觉得你对订单的举例,只是where条件中的一个条件,如果有其他条件怎么办? 其他查询大多是通过另外的搜索系统实现的,而不能直接在交易表上做查询的。 表连接应该也是要避免的。 |
|
返回顶楼 | |