Java电商毕业设计总结(一)

前言

最近快到毕业答辩的时候,我自己的论文也完成了查重,并且已经提交到知网平台。自己做的是一个电商项目,基本的功能都已实现。当时为了偷懒,直接是copy的慕课网上Spring电商的一个项目,自己在此基础改了几个星期,真心觉得代码写的烂。代码很多程度上违反了迪米特,合成复用,依赖倒置等原则。整体架构距离一致性,可用性,容错性有很大的差距。后期有时间,我会用Spring Cloud拆分整体模块,代码重构。

项目存在的问题

  • 1.20张表都是基础的CRUD。表与表之间的关系没有通过连接或者是嵌套进行关联,而是很大程序依赖去lambda代码去进行连接,导致效率很低。

  • 2.使用Timer进行任务调度不当(没有合理设置initialDelay时间或者是没有设置异步),会造成Eden区和Survivor区使用率太高,CPU占有率太高,严重影响性能,造成Tomcat响应速度很慢。建议用ScheduledExecutorService代替Timer,另外要注意newScheduledThreadPool的最大线程数是Integer.MAX_VALUE。使用的工作队列是DelayedWorkQueue,它是一个无界队列,会一直去消耗CPU性能直到殆尽。如果不了解线程池,最好手动创建。

  • 3.没有做前后端分离,前端路由过度依赖后端Controller的转发。

  • 4.自定义封装BaseMyBatisDAO,但是RowBounds分页功能效率很低,建议使用通用Mapper和PageHelper进行分页和排序。

  • 5.没有统一进行返回码封装和对异常的封装以及处理。

  • 6.重复代码太多,其实20张表的基础代码(Service层、Controller层、DAO层)完成可以用自动化框架生成。没必要把时间花在这些无意义的事情上,我们需要更关注于业务逻辑。

  • 7.图片服务器暂时是用Tomcat。明显不是一个好的选择,应该考虑七牛云或者搭建FastDFS。

  • 8.使用Redis缓存,无脑瞎B使用。设置的KEY也没有设置缓存失效时间。很多程度上没有考虑缓存穿透,缓存雪崩,缓存击穿这些场景,没有考虑到缓存数据和数据库里面的数据一致性的问题。

秒杀业务分析

在工作空余时间,也看了慕课网上关于高并发秒杀业务的解决方案,收货颇多。

1.商品详情页是产生高并发的一个点。中小型企业一般采用Nginx+页面静态化就能解决。我们可以把静态界面加入到CDN缓存中。CDN可以加速用户获取数据的速度,一般部署再离用户最近的网络节点上。

2.关于秒杀操作,我们无法去用CDN缓存。后端使用缓存比较困难,存在库存一致性的问题。在热度商品的秒杀上,存在一行数据竞争的情况。

3.关于秒杀地址暴露,我们也无法去用CDN缓存。适合用Redis进行缓存商品,一致性维护成本低。Redis和Mysql数据一致性维护可以采用超时穿透/主动更新策略。

4.关于获取秒杀时间的获取,其实不用优化。Java访问一次内存是10ns,而1秒等于=10亿ns。相当我1s的时间进行1亿次的new Date()。

5.比较成熟的解决方案: 原子计数器->Redis,记录行为消息->分布式MQ,消费消息并落地->MySQL。但是存在数据一致性和回滚问题,幂等性难以保证(会造成重复秒杀),这种架构不适合新手架构。

6.经过Jmeter压力测试,一条update商品库存语句的QPS是4W。一般用户进行秒杀操作,会受到网络延迟+GC的串行化阻塞。一般来说用户执行秒杀操作,正常的业务来说先执行减少商品库存操作,再插入用户购买明细。但是update同一行商品记录会造成行级锁。行级数会在commit事务后之后释放。在并发量集中的秒杀操作,这些操作会造成阻塞,因此我们优化的方向是减少行级锁持有的时间。我们可以先执行插入用户购买明细操作,然后更新库存操作。因为insert可以并行!

7.关于秒杀操作,我们可以把秒杀的业务逻辑写到MySQL端(也就是存储过程),整个事务在MySQL端完成,优化网络延迟和GC干扰。

优化总结:

1.前端控制:合理暴露秒杀地址,秒杀按钮防重复。

2.后端控制:动静态数据分离,CDN缓存,后端缓存,行级锁竞争优化,减少事务时间。

尾言

没有什么比学习和成长更为重要的事情了。
电商项目地址:https://github.com/cmazxiaoma/groupon
电商秒杀业务项目地址:https://github.com/cmazxiaoma/mallSeckill

点赞