内容简介:上几次主要说了高并发大流量项目所涉及到的技术点和技术方案,调优需要注意的一些参数,秒杀订单接口缓存的概念,通过redis的方式,redis需要进行原子性。使用缓存可以大大的提高我们系统的性能,但是需要考虑到周全,可能带来数据的不一致性,所以要根据业务的场景和业务的逻辑,良好的维护它,如果漏了就会产生服务的不一致。产生线上的bug。
上几次主要说了高并发大流量项目所涉及到的技术点和技术方案,调优需要注意的一些参数,秒杀订单接口缓存的概念,通过 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个人员,在加上单元测试人员,功能测试人员。分布式并发问题就是很复杂,复杂就是在细节里面,用数据库是可以查询出来实时的。
>>原创文章,欢迎转载。转载请注明:转载自,谢谢!>>原文链接地址:上一篇:已是最新文章
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 架构设计:异步处理流程,多种实现模式详解
- 全面异步化:淘宝反应式架构升级探索
- React 重要的一次重构:认识异步渲染架构 Fiber
- java – Tomcat连接器架构,线程池和异步servlet
- 数据驱动型的 IoT 体系架构设计,第 2 部分: 全异步的通用高性能物联网架构参考实践
- SpringBoot | :异步开发之异步调用
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。