nnngu 阅读(65) 评论(0)

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等架构进行分析

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

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