62,243
社区成员
发帖
与我相关
我的任务
分享如何优化多用户同时请求插入数据问题
例如购物网站中，同时有几千几万个用户一起请求购买，这时候如何能够优化数据插入呢？
如果一条条插入的话，要连接几千次数据库，性能上可能损失比较大。
我初步的想法是能不能缓存一下请求，比方说队列满100个请求，然后生成一个xml，传入数据库过程中，解析插入数据。
不过感觉这样效果也不见得好，有没有更好的处理方法，求教。
如果一条条插入的话，要连接几千次数据库，性能上可能损失比较大。
我初步的想法是能不能缓存一下请求，比方说队列满100个请求，然后生成一个xml，传入数据库过程中，解析插入数据。
不过感觉这样效果也不见得好，有没有更好的处理方法，求教。
...全文
请发表友善的回复…
发表回复
hl362496158 2011-05-31
- 打赏
- 举报
可以参照微薄的发布原理啊，微薄的数据量同时的请求很大的，
我一个同事以前跟我说过这方面的东西，可惜我人笨，现在不记得了，
好像是说什么，一条数据字段一直往后加什么的吧！
我一个同事以前跟我说过这方面的东西，可惜我人笨，现在不记得了，
好像是说什么，一条数据字段一直往后加什么的吧！
以专业开发人员为伍 2011-05-31
- 打赏
- 举报
考虑“根本不访问数据库”问题当然也是一种“解决方法”，但是其前提是业务逻辑的分析和设计思路就不是那种动不动只是读写数据库的思路。如果思路停留在关系数据库读写“技术”上，那么也就是这些技术上的优化方法。
以专业开发人员为伍 2011-05-31
- 打赏
- 举报
[Quote=引用楼主 lanwilliam 的回复:]
例如购物网站中，同时有几千几万个用户一起请求购买，这时候如何能够优化数据插入呢？
如果一条条插入的话，要连接几千次数据库，性能上可能损失比较大。
[/Quote]
你的意思是没有使用连接池？
例如购物网站中，同时有几千几万个用户一起请求购买，这时候如何能够优化数据插入呢？
如果一条条插入的话，要连接几千次数据库，性能上可能损失比较大。
[/Quote]
你的意思是没有使用连接池？
麦子的春天到了 2011-05-31
- 打赏
- 举报
围观~
格桑花 2011-05-31
- 打赏
- 举报
up...
凤凰涅檠 2011-05-31
- 打赏
- 举报
MARK UP 。。。
mayanly 2011-05-31
- 打赏
- 举报
路过！没遇到过这种问题。
alive501 2011-05-31
- 打赏
- 举报
购物网站算是OLTP , 单独的缓存的话数据库的ACID就没办法保证了. 肯定不能使用的. 只能从DB上想办法.
DB做并发优化 ,小表的话钉死在内存中.上并行服务器.
DB做并发优化 ,小表的话钉死在内存中.上并行服务器.
种草德鲁伊 2011-05-31
- 打赏
- 举报
好高端。
V-Far 2011-05-31
- 打赏
- 举报
有几千几万的时候估计要分布式了吧..单单一台服务器估计难做了
还没怎么考虑过这个问题
还没怎么考虑过这个问题
Lisliefor 2011-05-31
- 打赏
- 举报
可以优化保存数据的逻辑，只要插入效率高，释放链接快，小批量数据的频繁提交，一样不会有太大的问题。
Lisliefor 2011-05-31
- 打赏
- 举报
[Quote=引用楼主 lanwilliam 的回复:]
例如购物网站中，同时有几千几万个用户一起请求购买，这时候如何能够优化数据插入呢？
如果一条条插入的话，要连接几千次数据库，性能上可能损失比较大。
我初步的想法是能不能缓存一下请求，比方说队列满100个请求，然后生成一个xml，传入数据库过程中，解析插入数据。
不过感觉这样效果也不见得好，有没有更好的处理方法，求教。
[/Quote]
用缓存的话必然会面临数据延迟的问题。
另外，你要了解一个网站多少注册用户量，多少同时在线用户量，会对应多少并发，调查清楚这些数据，再想办法不迟，有经验的人知道数据库多少连接会满足多大的并发处理。
买东西不是一个短时间的过程，不存在你说的千万个人同时提交订单，你在做压力测试的时候，应该明白，每秒50条并发数据，实际会对应多少个同时在线的用户。
例如购物网站中，同时有几千几万个用户一起请求购买，这时候如何能够优化数据插入呢？
如果一条条插入的话，要连接几千次数据库，性能上可能损失比较大。
我初步的想法是能不能缓存一下请求，比方说队列满100个请求，然后生成一个xml，传入数据库过程中，解析插入数据。
不过感觉这样效果也不见得好，有没有更好的处理方法，求教。
[/Quote]
用缓存的话必然会面临数据延迟的问题。
另外，你要了解一个网站多少注册用户量，多少同时在线用户量，会对应多少并发，调查清楚这些数据，再想办法不迟，有经验的人知道数据库多少连接会满足多大的并发处理。
买东西不是一个短时间的过程，不存在你说的千万个人同时提交订单，你在做压力测试的时候，应该明白，每秒50条并发数据，实际会对应多少个同时在线的用户。
xiuyer 2011-05-31
- 打赏
- 举报
客户至上，我觉得还是有一个插一个好。。。
RUNBEAR 2011-05-31
- 打赏
- 举报
[Quote=引用 12 楼 lanwilliam 的回复:]
不一定几千几十万啊？可能就是有个几百并发，但是如果插入100次的话，可能就需要几秒哦，综合一下，创建cache，插入条件为
1. 定时更新
2. 满100更新
继续等。。。。
[/Quote]
如果服务器死机，重启等原因，CACHE不就没了？文件还好一点吧。
不一定几千几十万啊？可能就是有个几百并发，但是如果插入100次的话，可能就需要几秒哦，综合一下，创建cache，插入条件为
1. 定时更新
2. 满100更新
继续等。。。。
[/Quote]
如果服务器死机，重启等原因，CACHE不就没了？文件还好一点吧。
怪蜀黍的花季雨季 2011-05-31
- 打赏
- 举报
写个事物来解决,,,或者做一个并发处理功能！
X1656732236 2011-05-31
- 打赏
- 举报
我不知道你所说的同时是多长时间，如果一秒内写入100条数据，一天下来就有84万多条数据。还只是一个表，还没有算查询，更新这些操作。
X1656732236 2011-05-31
- 打赏
- 举报
楼主你的想法是没对的。
第一：如果使用服务器端缓存，如果服务器重启怎么办？
第二：如果使用客户端缓存，如果用户只买一件商品你怎么处理。
基于WEB的程序本身就是多用户可同时操作的，你所要做的优化就是让每一次数据写入或更新更快就可以了。
如果老板要求什么同时写入几千几万条数据，那不是一台服务器所能办到的，一个办法加服务器或加工资。
第一：如果使用服务器端缓存，如果服务器重启怎么办？
第二：如果使用客户端缓存，如果用户只买一件商品你怎么处理。
基于WEB的程序本身就是多用户可同时操作的，你所要做的优化就是让每一次数据写入或更新更快就可以了。
如果老板要求什么同时写入几千几万条数据，那不是一台服务器所能办到的，一个办法加服务器或加工资。
著名天才___ 2011-05-31
- 打赏
- 举报
这个问题值得研究哟、
b哈利路亚d 2011-05-31
- 打赏
- 举报
不一定几千几十万啊？可能就是有个几百并发，但是如果插入100次的话，可能就需要几秒哦，综合一下，创建cache，插入条件为
1. 定时更新
2. 满100更新
继续等。。。。
1. 定时更新
2. 满100更新
继续等。。。。
langxingcs 2011-05-11
- 打赏
- 举报
数据库一般的请求没有问题。
加载更多回复（9）
