请稍等 ...
×

采纳答案成功!

向帮助你的同学说点啥吧!感谢那些助人为乐的人

写订单场景的压测数据没有吗

整个方案不完整,如何证明瞬时涌入的成功订单的写数据操作不会把数据库卡死

正在回答

1回答

一凡 2019-06-21 14:15:42

这就是分布式集群要考虑的关键点呀。

看库存的规模,如果只有1w库存,那么数据库一秒钟生成1w订单,拥堵一秒钟的订单请求也就没问题,毕竟前面会有redis和nginx挡住流量。

如果是更高的并发和库存数量,就要考虑多集群的方案了,课程中都是有介绍呀。

0 回复 有任何疑惑可以回复我~
  • 提问者 慕前端1322202 #1
    老师的意思是读操作尽量用nginx和redis来挡,并发写操作全部同步打到数据库。如果一个数据库集群扛不住的话,不太明白你说的集群部署方案是指什么?视频里只提到了多数据中心方案,直接跳到这步是不是成本有点高。
    回复 有任何疑惑可以回复我~ 2019-06-27 22:35:15
  • 一凡 回复 提问者 慕前端1322202 #2
    相对于更大规模的秒杀情景,这部分的服务器资源已经是很少的投入了。想想看,什么公司会遇到数万的商品上百万人同时抢,极少见,所以这时候临时投入几百台服务器根本不是难点,关键还是系统架构能够支持,而不用来回重构优化的折腾。
    回复 有任何疑惑可以回复我~ 2019-06-28 10:47:14
  • 提问者 慕前端1322202 回复 一凡 #3
    投入服务器的数量成本确实可以忽略,我不是指这个成本。仅仅是因为数据库并发写的压力就要切换到多数据中心方案是不是有点步子跨太大了?这对于绝大多数的系统甚至不是可选方案。如果老师认为确实不需要什么中间方案,能否给出推导过程和数据支撑呢?
    另外,教程的压测只有读数据,并没有写数据的测试。要证明一个抢购系统可用,这应该是必须的吧。无论目标抢购人数是什么级别的。
    回复 有任何疑惑可以回复我~ 2019-06-29 10:53:39
问题已解决,确定采纳
还有疑问,暂不采纳
意见反馈 帮助中心 APP下载
官方微信