简历项目总结

View(页面)>Controller(控制层)>Service(业务逻辑层)>Dao(数据访问层)>database(数据库)

详情页-系统时间-倒计时-地址暴露接口-执行秒杀操作-返回结果

加粗部分是可能出现高并发的点

1.详情页

为什么单独获取系统时间:

用户大量刷新页面-》CDN(detai页静态化,静态资源css,js等)/其他请求对对应秒杀系统上

对CDN(内容分发网络)的理解

  加速用户获取数据的系统(大部分视频都依赖于CDN)

  部署在离用户最近的网络节点上

   命中的CDN不需要访问后端服务器

   互联网公司自己搭建或租用

获取系统时间不用优化,java访问一次内存大约10ns(1s等于10亿ns)

2.获取秒杀地址的分析

无法使用CDN缓存(因为秒杀地址随着时间的推移进行了变化,如秒杀未开启,秒杀开启,秒杀结束)

适合服务器端缓存:redis等(内存的缓存,可以抗很高的TPS(每秒事务量),官方给的是一秒钟10万个TPS)

redis还可以做集群,集群之后可以抗百万的TPS(先访问数据库,拿到秒杀的数据,然后把它放到redis缓存里,然后下次查找直接从redis里面取)

一致性维护成本低(当我们秒杀的对象改变的时候,我们可以修改数据库,在修改redis里的,或者也可以不改,等超超之后再改)

秒杀地址接口的优化:

请求地址-》redis-》mysql(一致性维护 (超时穿透/主动更新)比如说我缓存半个小时,半个小时之后redis中的秒杀对象就会超时,超时之后就穿透到我们的mysql,当我们的mysql主动更新的时候我们主动更新一下我们的redis)3.

3.秒杀操作优化分析

无法使用CDN缓存;后端缓存比较困难:库存问题(该项目使用mysql事务,保证数据的一致性);一行数据的竞争(对mysql数据的执行大量的update减库存操作竞争)

原子计数器-技术-redis(原子计数器就是当前库存,当用户进来执行秒杀的时候会去减库存,保证automic原子性,去记录行为消息-》放到分布式的MQ当中,后端的服务会去消费这个消息并落地-mysql当中)该架构会抗住非常高的并发;痛点:成本分析,运维成本和稳定性:Nosql,MQ等(需要强大的运维团队去支持这些分布式组件的稳定性);开发成本:数据一致性,回滚方案等;幂等性很难保证:重复秒杀问题(当减库存的时候,其实他不知道之前这用户有没有减过库存,再去发一个消息,这个用户又去对这个商品做了秒杀,一般的操作是还要去维护一个分布式的nosql的i/o访问方案,就是记录哪些用户已经减内存了)

行级锁在commit之后释放;优化方向是如何减少行级锁的持有时间;update之后java有可能存在gc操作,GC一般是50ms

延迟问题的分析:


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值