04 整合IDEA+Maven+SSM框架的高并发的商品秒杀项目之高并发优化

Github：https://github.com/nnngu

项目源代码：https://github.com/nnngu/nguSeckill

---

关于并发

并发性上不去是因为当多个线程同时访问一行数据时，产生了事务，因此产生写锁，当一个获取了事务的线程把锁释放，另一个排队线程才能拿到写锁，QPS(Query Per Second每秒查询率)和事务执行的时间有密切关系，事务执行时间越短，并发性越高，这也是要将费时的 IO 操作移出事务的原因。

项目中的高并发发生在哪？

下图中，红色的部分就表示会发生高并发的地方，绿色部分表示对于高并发没有影响。

为什么要单独获取系统时间？

这是为了我们的秒杀系统的优化做铺垫。比如在秒杀还未开始的时候，用户大量刷新秒杀商品详情页面是很正常的情况，这时候秒杀还未开始，大量的请求发送到服务器会造成不必要的负担。

我们将这个详情页放置到CDN中，这样用户在访问该页面时就不需要访问我们的服务器了，起到了降低服务器压力的作用。而CDN中存储的是静态化的详情页和一些静态资源（css，js等），这样我们就拿不到系统的时间来进行秒杀时段的控制，所以我们需要单独设计一个请求来获取我们服务器的系统时间。

CDN（Content Delivery Network）的理解

获取系统时间不需要优化

因为Java访问一次内存（Cacheline）大约10ns，1s=10亿ns，也就是如果不考虑GC，这个操作1s可以做1亿次。

秒杀地址接口分析

• 无法使用CDN缓存，因为CDN适合请求对应的资源不变化的，比如静态资源、JavaScript；秒杀地址返回的数据是变化的，不适合放在CDN缓存；

• 适合服务端缓存：Redis等，1秒钟可以承受10万QPS。多个Redis组成集群，可以到100万个QPS。所以后端缓存可以用业务系统控制。

秒杀地址接口优化

秒杀操作优化分析

• 无法使用cdn缓存

• 后端缓存困难： 库存问题

• 一行数据竞争：热门商品

大部分写的操作和核心操作无法使用CDN，也不可能在缓存中减库存。你在Redis中减库存，那么用户也可能通过缓存来减库存，这样库存会不一致，所以要通过mysql的事务来保证一致性。

比如一个热门商品所有人都在抢，那么会在同一时间对数据表中的一行数据进行大量的update set操作。

行级锁在commit之后才释放，所以优化方向是减少行级锁的持有时间。

延迟问题很关键

• 同城机房网络（0.5ms~2ms），最高并发性是1000qps。

• update后JVM -GC(垃圾回收机制)大约50ms，最高并发性是20qps。并发性越高，GC就越可能发生，虽然不一定每次都会发生，但一定会发生。

• 异地机房，比如北京到上海之间的网络延迟，经过计算大概13~20ms。

如何判断update更新库存成功？

有两个条件：

• update自身没报错；

• 客户端确认update影响记录数

优化思路：把客户端逻辑放到MySQL服务端，避免网络延迟和GC影响

如何把客户端逻辑放到MySQL服务端

有两种方案：

• 定制SQL方案，在每次update后都会自动提交，但需要修改MySQL源码，成本很高，不是大公司（BAT等）一般不会使用这种方法。

• 使用存储过程：整个事务在MySQL端完成，用存储过程写业务逻辑，服务端负责调用。

接下来先分析第一种方案

根据上图的成本分析，我们的秒杀系统采用第二种方案，即使用存储过程。

优化总结

• 前端控制。暴露接口，按钮防重复（点击一次按钮后就变成灰色，禁止重复点击按钮）

• 动静态数据分离。CDN缓存，后端缓存

• 事务竞争优化。减少事务行级锁的持有时间

下载安装Redis

Redis是一个开源的、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库

下载安装Redis的步骤，搜索引擎能找到相关的资料，本文不做展开。

下载安装完Redis之后就可以继续进行操作。

使用Java操作Redis

Java操作Redis使用的是jedis包。

在pom.xml添加jedis的依赖，如下图：

添加protostuff-core 以及protostuff-runtime 序列化jar包，如下图：

序列化是处理对象流的机制，就是将对象的内容进行流化，可以对流化后的对象进行读写操作，也可以将流化后的对象在网络间传输。反序列化就是将流化后的对象重新转化成原来的对象。

在Java中内置了序列化机制，通过implements Serializable来标识一个对象实现了序列化接口，不过其性能并不高。

建立操作Redis的dao类

原本查询秒杀商品时是通过主键直接去数据库查询的，选择将数据缓存在Redis，在查询秒杀商品时先去Redis缓存中查询，以此降低数据库的压力。如果在缓存中查询不到数据再去数据库中查询，再将查询到的数据放入Redis缓存中，这样下次就可以直接去缓存中直接查询到。

添加RedisDao.java文件，位于下图所示的位置：

RedisDao.java文件里面的代码请参照项目的源代码。

在applicationContext-dao.xml中注入redisDao

在applicationContext-dao.xml中添加下图所示的内容：

改造exportSeckillUrl方法：

修改SeckillServiceImpl.java文件中的exportSeckillUrl方法：

/**
     * 在秒杀开启时输出秒杀接口的地址，否则输出系统时间跟秒杀地址
     *
     * @param seckillId 秒杀商品Id
     * @return 根据对应的状态返回对应的状态实体
     */
    @Override
    public Exposer exportSeckillUrl(long seckillId) {

        Seckill seckill = redisDao.getSeckill(seckillId);
        if (seckill == null) {
            // 访问数据库读取数据
            seckill = seckillMapper.queryById(seckillId);
            if (seckill == null) {
                return new Exposer(false, seckillId);
            } else {
                // 放入redis
                redisDao.putSeckill(seckill);
            }
        }

        // 判断是否还没到秒杀时间或者是过了秒杀时间
        Date startTime = seckill.getStartTime();
        Date endTime = seckill.getEndTime();
        Date nowTime = new Date();
        // 开始时间大于现在的时候说明没有开始秒杀活动；秒杀活动结束时间小于现在的时间说明秒杀已经结束了
        if (nowTime.getTime() > startTime.getTime() && nowTime.getTime() < endTime.getTime()) {
            //秒杀开启,返回秒杀商品的id,用给接口加密的md5
            String md5 = getMd5(seckillId);
            return new Exposer(true, md5, seckillId);
        }
        return new Exposer(false, seckillId, nowTime.getTime(), startTime.getTime(), endTime.getTime());

    }

简单的优化

以前的实现流程：

用户的秒杀操作分为两步：减库存、插入购买明细，我们在这里进行简单的优化，就是将原本先update（减库存）再进行insert（插入购买明细）的步骤改成：先insert再update。

为什么要先insert再update

• 首先是在更新操作的时候给行加锁，插入并不会加锁，如果更新操作在前，那么就需要执行完更新和插入以后事务提交或回滚才释放锁。而如果插入在前，更新在后，那么只有在更新时才会加行锁，之后在更新完以后事务提交或回滚释放锁。

• 在这里，插入是可以并行的，而更新由于会加行级锁是串行的。

• 也就是说是如果更新在前，加锁和释放锁之间两次的网络延迟和GC，如果更新在后，则加锁和释放锁之间只有一次的网络延迟和GC，也就是减少的持有锁的时间。

• 这里先insert并不是忽略了库存不足的情况，而是因为insert和update是在同一个事务里，光是insert并不一定会提交，只有在update成功才会提交，所以并不会造成过量插入秒杀成功记录。

去代码里改造执行秒杀的executeSeckill()方法，优化性能。

深度优化（使用存储过程）

前边通过调整insert和update的执行顺序来实现简单的优化，但依然存在着Java客户端和服务器通信时的网络延迟和GC影响，我们可以将执行秒杀操作时的insert和update放到MySQL服务端的存储过程里，而Java客户端直接调用这个存储过程，这样就可以避免网络延迟和可能发生的GC影响。另外，由于我们使用了存储过程，也就用不到Spring的事务管理了，因为在存储过程里我们会直接启用一个事务。

去MySQL的控制台执行储存过程procedure.sql里面的代码

去MySQL的控制台执行储存过程procedure.sql里面的代码。

procedure.sql文件位于项目的sql目录下。

注意点：在存储过程中，row_count() 函数用来返回上一条 sql（delete, insert, update）影响的行数。

根据row_count() 的返回值，可以进行接下来的流程判断：

0：未修改数据；

>0：表示修改的行数；

<0：表示SQL错误或未执行修改SQL

修改源码以调用存储过程

在SeckillMapper.java接口中声明killByProcedure()方法

    /**
     * 使用储存过程执行秒杀
     *
     * @param paramMap
     */
    void killByProcedure(Map<String, Object> paramMap);

然后在SeckillMapper.xml中写sql语句，具体代码请参照项目的源代码。

接着在SeckillService.java接口中声明 executeSeckillProcedure()方法

在pom.xml中添加commons-collections的依赖，如下图：

然后在SeckillServiceImpl.java中实现executeSeckillProcedure()方法。

在SeckillServiceImplTest.java中编写测试方法executeSeckillProcedureTest()。

测试结果：

修改SeckillController.java中的execute()方法，把一开始调用普通方法的改成调用储存过程的方法。

存储过程优化总结

• 存储过程优化：事务行级锁持有的时间

• 不要过度依赖存储过程

• 简单的逻辑依赖存储过程

• QPS:一个秒杀单6000/qps

经过简单优化和深度优化之后，本项目大概能达到一个秒杀单6000qps，这个数据对于一个秒杀商品来说其实已经挺ok了，注意这里是指同一个秒杀商品6000qps，如果是不同商品不存在行级锁竞争的问题。

系统部署架构

CDN：放置一些静态化资源，或者可以将动态数据分离。一些js依赖直接用公网的CDN，自己开发的一些页面也做静态化处理推送到CDN。用户在CDN获取到的数据不需要再访问我们的服务器，动静态分离可以降低服务器请求量。比如秒杀详情页，做成HTML放在CDN上，动态数据可以通过ajax请求后台获取。

Nginx：作为http服务器，响应客户请求，为后端的servlet容器做反向代理，以达到负载均衡的效果。

Redis：用来做服务器端的缓存，通过Jedis提供的API来达到热点数据的一个快速存取的过程，减少数据库的请求量。

MySQL：保证秒杀过程的数据一致性与完整性。

智能DNS解析+智能CDN加速+Nginx并发+Redis缓存+MySQL分库分表，如下图：

大型系统部署架构，逻辑集群就是开发的部分。

• Nginx做负载均衡

• 分库分表：在秒杀系统中，一般通过关键的秒杀商品id取模进行分库分表，以512为一张表，1024为一张表。分库分表一般采用开源架构，如阿里巴巴的tddl分库分表框架。

• 统计分析：一般使用hadoop等架构进行分析

在这样一个架构中，可能参与的角色如下：

到此，该项目已经全部完成，感谢阅读本文。

我的博客即将搬运同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan