简历项目总结

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

延迟问题的分析：