章节目录

• 1.为什么使用Spring+Spring MVC+Mybatis
• 2.秒杀业务特性
• 3.秒杀分析过程、优化思路
• 4.相关技术介绍
• 5.基于Maven创建项目
• 6.秒杀业务分析
• 7.秒杀事务的难点分析
• 8.实现秒杀的哪些功能

1.为什么使用Spring+Spring MVC+Mybatis

• 框架易于使用、轻量级
• 对业务代码侵入性低
• 成熟的社区与资料

2.秒杀业务特性

• 秒杀业务场景具有典型的"事务"特性
• 秒杀、红包类需求越来越常见，对竞争资源的访问
• 面试常问的问题

3.相关技术介绍

• MySQL
  • 表设计
  • SQL技巧
  • 事务、行级锁
• MyBatis
  • DAO层设计与开发
  • MyBatis 合理使用
  • MyBatis 与 Spring整合
• Spring
  • Spring Ioc 整合Service
  • Spring 声明式事务使用
• Spring MVC
  • Restful 接口设计与使用
  • 框架运作流程
  • Controller 设计技巧
• 前端
  • 交互设计
  • BootStrap
  • Jquery
• 高并发
  • 高并发点和高并发分析
  • 优化思路并实现

4.基于Maven创建项目

1.maven命令创建web项目骨架

mvn archetype:generate -DgroupId=org.seckill -DartifactId=seckill -DarchetypeArtifactId=maven-archetype-webapp

5.秒杀业务分析

如下图所示：

所以秒杀业务的核心是对库存的处理。

用户针对库存处理的业务分析

用户的秒杀过程

需要减库存->记录购买明细->组成完整事务->数据持久化

如下图所示：

用户购买行为

记录谁购买成功了->成功的时间及有效期->付款、发货信息

为什么需要事务

如上图所示1.减了库存，但是没有用户的购买明细，那么就会出现50个商品，但是购买明细小于50个，到时候发货会发现有些许商品滞留在仓库中，此种情况属于少卖的情况。2.记录了明细但是没有减库存，就会发现订单量比商品量要多，出现超卖的情况，还有一种情况也会导致超卖，多个用户并发修改库存，加入库存量为1，这个时候多个用户同时去减库存（经过库存量>0的验证），会导致库存为负数，多个用户抢到同一个商品，这种情况下也会导致超卖发生。

数据落地方案

MySQL VS NoSQL NoSQL非关系型数据库在事务的支持上并没有关系型数据库可靠。 所以归根结底事务机制依然是目前最可靠的落地方案。

6.秒杀事务难点分析

6.1 难点问题-竞争

解决方案是采用数据库innodb引擎提供的 事务及 行级锁。

• 用户减库存的事务流程：

  begin;update 库存数量;insert 购买明细；commit;

• 行级锁
  如下如所示:
  

  行级锁
  情景分析：

在事务执行过程中，mysql默认的repeateable read 隔离级别会在写操作发生的行上加上行级锁（非记录加锁，而是在对应索引上加锁，上图中的update加锁发生在id上），多个写请求并发更新同一行记录会产生如下问题：因为行级锁在事务结束之后才能释放锁，可能会导致锁等待的发生。数据库吞吐率（事务处理能力）会降低。

所以秒杀的难点是什么？

秒杀的难点是如何高效的处理竞争-如何在保证数据一致性的情况下高效的处理竞争

8.实现秒杀的哪些功能

• 1.秒杀接口暴露
  浏览器插件获取秒杀接口，通过脚本去秒杀，保护秒杀接口的一种手段。
• 2.执行秒杀的操作
  执行秒杀的业务逻辑
• 3.秒杀查询，商品详情页查询。

其实市面上最主要的几个秒杀思路是：

1.直接在数据库层面做秒杀

2.缓存中存储库存，用户秒杀请求是将缓存中库存与数据库中库存数据同时进行减库存的过程，保证数据一致性是一个难点。

3.缓存中存储有效的减库存操作，队列减库存的的请求依次顺序执行数据库减库存、生成订单明细事务(操作)，如小米。