|
锁定老帖子 主题：淘宝下单高并发解决方案
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-05-15
yukaizhao 写道 BloodyCoder 写道 分表查询有利，插入数据怎么办？如何保证数据插入主键的全局惟一性？
GUID是可以解决问题，不过GUID效率似乎有点低。可以用一个专门的算法生成ID号。 效率是一方面，对于交易多数是需要的流水号。 这个分库分表之后对流水号支持并发和全局唯一也有相应的要求。 支付宝的交易流水号应该是日期+随机+最后2位估计是用户ID取模。 在分库分表的情况下不知道有什么好的办法来保证流水号的唯一性是个问题. |
| 返回顶楼 | |
|
发表时间：2012-05-16
yukaizhao 写道 BloodyCoder 写道 分表查询有利，插入数据怎么办？如何保证数据插入主键的全局惟一性？
GUID是可以解决问题，不过GUID效率似乎有点低。可以用一个专门的算法生成ID号。 低的理由是什么？ |
| 返回顶楼 | |
|
发表时间：2012-05-20
这几天抽出时间来做了下测试，发现分表后性和分表前是一样的，我做的测试是这样的：
将用户表和订单表分成2份，分别是acct1,acct2,flow1,flow2,然后根据userid的操作不同的，如果userid是奇数，就写flow1表，然后扣除acct1中的账户余额，如果userid是偶数，就写flow2表，然后扣除acct2中的账户余额，mysql数据库的max_connections我设置成300了，在实际的测试过程中，模拟的并发线程数是50个。 |
| 返回顶楼 | |
|
发表时间：2012-05-22
codeone 写道 这几天抽出时间来做了下测试，发现分表后性和分表前是一样的，我做的测试是这样的：
将用户表和订单表分成2份，分别是acct1,acct2,flow1,flow2,然后根据userid的操作不同的，如果userid是奇数，就写flow1表，然后扣除acct1中的账户余额，如果userid是偶数，就写flow2表，然后扣除acct2中的账户余额，mysql数据库的max_connections我设置成300了，在实际的测试过程中，模拟的并发线程数是50个。 账户余额走的另外一个系统（支付宝）。你这样在本地做的测试是不合适的，服务器硬盘io都不一样的，另外mysql的设置也可能是不一样的。 |
| 返回顶楼 | |
|
发表时间：2012-05-23
yukaizhao 写道 codeone 写道 这几天抽出时间来做了下测试，发现分表后性和分表前是一样的，我做的测试是这样的：
将用户表和订单表分成2份，分别是acct1,acct2,flow1,flow2,然后根据userid的操作不同的，如果userid是奇数，就写flow1表，然后扣除acct1中的账户余额，如果userid是偶数，就写flow2表，然后扣除acct2中的账户余额，mysql数据库的max_connections我设置成300了，在实际的测试过程中，模拟的并发线程数是50个。 账户余额走的另外一个系统（支付宝）。你这样在本地做的测试是不合适的，服务器硬盘io都不一样的，另外mysql的设置也可能是不一样的。 恩，多谢楼主解答，将mysql的innodb_thread_concurrency参数改为0后，性能可以达到100个并发，平均每个并发耗时300MS，但是分表和不分表结果差不多，如果并发增加到200个，分表的性能比不分表性能高4倍，分表的性能是平均每个并发耗时1500MS， 我认为在我本机测试，性能会比服务器低，但是分表的性能理论上肯定要高于不分表。 |
| 返回顶楼 | |
|
发表时间：2012-05-23
codeone 写道 yukaizhao 写道 codeone 写道 这几天抽出时间来做了下测试，发现分表后性和分表前是一样的，我做的测试是这样的：
将用户表和订单表分成2份，分别是acct1,acct2,flow1,flow2,然后根据userid的操作不同的，如果userid是奇数，就写flow1表，然后扣除acct1中的账户余额，如果userid是偶数，就写flow2表，然后扣除acct2中的账户余额，mysql数据库的max_connections我设置成300了，在实际的测试过程中，模拟的并发线程数是50个。 账户余额走的另外一个系统（支付宝）。你这样在本地做的测试是不合适的，服务器硬盘io都不一样的，另外mysql的设置也可能是不一样的。 恩，多谢楼主解答，将mysql的innodb_thread_concurrency参数改为0后，性能可以达到100个并发，平均每个并发耗时300MS，但是分表和不分表结果差不多，如果并发增加到200个，分表的性能比不分表性能高4倍，分表的性能是平均每个并发耗时1500MS， 我认为在我本机测试，性能会比服务器低，但是分表的性能理论上肯定要高于不分表。 我个人理解分表之后肯定会提高并发，减少锁表的可能。 |
| 返回顶楼 | |
|
发表时间：2012-05-23
montya 写道 yukaizhao 写道 订单号介绍勘误：
文中对于订单号的表述有点问题，对于16台服务器，每台服务器64张表只需要2位买家或卖家id的后两位数字就可以准确定位到具体的库和表。订单号中同时存在买家id的最后两位和卖家id的最后两位。分别在订单号的倒数第3，4位数和最后两位数。 假定买家id为123456789，那么在订单号中的最后两位就是89，通过89对16取模就可以定位到具体的库上，通过对64取模就可以定位到具体的表上。 简单靠取模来判断数据和表，不太好吧。 如果后期有新表和服务器。加入呢。 用类似memcache 中一致性hash。不知道怎么样。 既然用了取模就想着不加服务器了 |
| 返回顶楼 | |
|
发表时间：2013-03-24
yukaizhao 写道 订单号介绍勘误：
文中对于订单号的表述有点问题，对于16台服务器，每台服务器64张表只需要2位买家或卖家id的后两位数字就可以准确定位到具体的库和表。订单号中同时存在买家id的最后两位和卖家id的最后两位。分别在订单号的倒数第3，4位数和最后两位数。 假定买家id为123456789，那么在订单号中的最后两位就是89，通过89对16取模就可以定位到具体的库上，通过对64取模就可以定位到具体的表上。 我看了下我的订单，后四位都是一样的。后四位是全是买家的id吧。 |
| 返回顶楼 | |
