『互联网架构』软件架构-解密电商系统-秒杀消息队列异步下单(79)

上几次主要说了高并发大流量项目所涉及到的技术点和技术方案,调优需要注意的一些参数,秒杀订单接口缓存的概念,通过redis的方式,redis需要进行原子性。

秒杀优化

使用缓存可以大大的提高我们系统的性能,但是需要考虑到周全,可能带来数据的不一致性,所以要根据业务的场景和业务的逻辑,良好的维护它,如果漏了就会产生服务的不一致。产生线上的bug。

  • 地址信息

    正常的下秒杀单子的时候,需要先维护好地址信息,下单的时候需要提供对应的地址信息。也可以将这些地址信息添加到redis中,当用户登录的时候的默认从redis中获取地址信息,这样就可以增加性能,但是还有个问题,用户的地址会登录后发生变化,也就是在用户针对地址发生变化的时候,维护当前用户redis的地址。

  • 下单校验

    如果库存有50个,请求过来5050个,最后下单成功了50个,但是其他5000个都要走一遍查询流程是不是不应该,应该让他走一半就结束,不应该走到最后的库存查询就才结束,应该在库存查询之前要走各种session校验,地址校验,信息校验各种。应该在前面有个jvm内存的校验直接就先告诉他库存已经少于等于0了就不要在往下面请求了,这样服务压力不会很大。也就是在内存中jvm中有个变量来进行判断通过hash的方式。

  • 下单异步化

    下单后,可以进行消息处理中,让消息消费端慢慢消费消息中间件内的消息。使用异步化下单后不能直接跳转到支付页面,可能订单还没生成,还在排队,肯定不能直接返回待支付页面,跟他返回排队中。异步队列效果最佳就是底层库存比较大的情况下。这样吞吐量比较大。

(二)前端控制

原来的时候下单完毕后,直接跳转到支付页面。如果是做成异步下单,就不能直接跳转到支付页面了,而是需要在等待页面,等待页面有个js方法定时循环的调用获取这个用户是否在数据库存在单子,如果存在就直接跳转支付页面,如果不存在就一直等待,在等待的过程中如果库存为0,说明已经抢完了,失败了,没有最后落单,就直接通过客户下单失败,秒杀结束。千万没查数据库了,查redis就可以了。

PS:BAT这种大公司里面的秒杀系统,一般涉及到7,8个中心,每个中心之前可能有2个开发人员,一个秒杀系统大概15,16个人员,在加上单元测试人员,功能测试人员。分布式并发问题就是很复杂,复杂就是在细节里面,用数据库是可以查询出来实时的。

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:『互联网架构』软件架构-解密电商系统-秒杀消息队列异步下单(79)
上一篇: 下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注