SSM(Spring+SpringMVC+MyBatis)高并发优化思路

时间:2022-12-20 17:14:07

SSM(Spring+SpringMVC+MyBatis)框架集由Spring、MyBatis两个开源框架整合而成(SpringMVC是Spring中的部分内容)。常作为数据源较简单的web项目的框架。

学习课程的地址:https://www.imooc.com/learn/632

老师的GitHub地址:https://github.com/geekyijun/seckill

高并发发生在哪里?
分析整个系统流程,用户进行秒杀时最感兴趣的进入详情页进行秒杀。图中红色表示可能会出现高并发的点,绿色表示不会出现高并发。

SSM(Spring+SpringMVC+MyBatis)高并发优化思路

为什么要单独获取系统时间?
用户进行大量刷新时,详情页会部署到CDN节点上,进行静态化处理同时包括静态资源(css/js等)。这样就难以获得系统的统一秒杀时间。

CDN(内容分发网络)加速用户获取数据的系统,部署在离用户最近的网络节点上,命中CDN不需要访问后端服务器,互联网公司一般自己搭建或租用CDN服务器。涉及到CDN知识,进公司后涉及到自然就会了。。。

获取系统时间不用进行优化,因为访问内存的速度相当快。

秒杀地址接口分析
       无法使用CDN,使用CDN一般是不便的资源,而这里返回秒杀地址是变化的。适合使用服务端缓存如redis等。

流程则是先访问redis,如果redis中没有再去数据库中寻找,即redis是数据库的一个映射(后面得学下redis。。。),这里涉及到一致性问题,使用超时穿透/主动更新的方法。

秒杀操作的优化分析
无法使用CDN,库存量缓存困难,一行数据竞争(热点商品)。

为什么说MySQL低效?测试里MySQL的一条update一秒钟可以进行4W多次,不算低。主要是因为行级锁,每个用户都进行update,进行事务操作,等待锁的过程变成了串行化的操作。行级锁是在commit之后释放,优化的方向则是如何减少行级锁的持有时间。

延迟的分析:物理上的距离、JVM的GC问题。将客户端运行在MySQL端。方案一:定制SQL方案,需要修改MySQL源码。方案二:使用存储过程,整个事务在MySQL端完成。(这一段需要查更多资料)。

总结
前端控制:暴露接口、按钮防重复

动静态数据分离:CDN缓存、后端缓存

事务竞争优化:减少事务锁时间

redis后端缓存优化
redis目前官网不支持Windows,不过微软做了一个win64的版本。

具体编码这里不贴出了(见GitHub:https://github.com/geekyijun/seckill),理解原理就好。需要用到高并发时候可以详细学习一下。大致的思路就是访问redis缓存有没有数据,有就直接读,没有再读数据库并更新redis缓存。一致性通过设置一段时间后redis失效(超时穿透)和更新数据库时同时更新redis缓存(主动更新)。

秒杀操作—并发优化
将update减库存和insert购买明细进行顺序调整,将减少行级锁的时间,不必担心insert的问题,因为减库存成功后才commit否则rollback。但是这么做减少一半的网络延时和GC时间。关注点在哪些事务的操作中对数据库的行级锁有竞争关系,将行级锁的更新压缩到最小。

SSM(Spring+SpringMVC+MyBatis)高并发优化思路

深度优化:将逻辑判断直接以函数的形式写入MySQL。

-- 存储过程

-- 1:存储过程优化:事务行级锁持有的时间

-- 2:不要过度依赖存储过程(一般存在于银行,互联网公司很少使用,秒杀单有用的地方)

-- 3:简单的逻辑可以应用存储过程

-- 4:QPS:一个秒杀单6000/qps

GitHub上有这一段的源码。

系统的部署架构

SSM(Spring+SpringMVC+MyBatis)高并发优化思路

讲解了关于高并发下秒杀的简单案例(当然现实比这个复杂的多),感谢大牛。

原文地址