秒杀系统的搭建

最新推荐文章于 2024-06-30 21:30:36 发布

石榴爸爸鸭

最新推荐文章于 2024-06-30 21:30:36 发布

阅读量503

点赞数

文章标签： redis java 分布式

本文链接：https://blog.csdn.net/shiliu_baba/article/details/108434868

版权

秒杀系统的搭建思路

在如今这个流量就是金钱的时代，秒杀活动无疑还是一个非常吸引流量的活动，各大电商平台都会推出类似双11这样的大促活动，那么如何保证这种高并发情况下的秒杀系统的正常运行，就变成了程序员需要重点考虑的一个问题了。

一、构建思路：

其实，针对秒杀活动的高并发，其实可以分为大量的并发读请求和大量的并发写请求。我们也就是要针对这两类请求来进行针对性处理。

但是，这两类请求也有一些共同的处理思路，那就是4要1不要。

1.数据量要尽可能的小

不管是读请求还是写请求，其实都是针对数据来进行操作的。而数据的传输是会消耗时间的，不管是网络中的数据传输，还是我们服务器中的数据传输。而我们在服务器中对数据进行的处理是非常消耗CPU的。

而数据一般都是会与数据库进行打交道的，这又涉及到了序列化与反序列化，这也是一个非常消耗CPU的，所以，保证数据尽可能的小，数据格式尽可能的简单，与数据库打交道尽可能的少。

2.请求数量要尽可能的少

这里说的请求数量不是只用户访问我们服务器的请求数量，而是用户一个访问请求，我们自己渲染页面所需要的请求数量，比如说访问页面的时候后端接口的调用，页面依赖的资源的加载，Ajax请求等。而每一个请求无疑都是会消耗资源的，所以请求数量要保证尽可能的少。

3.请求路径要尽可能的短

这里说的路径是指的是一个请求过来，我们处理请求到返回要经过的节点。

一般来说，一个请求进来，经过节点的时候都要创建一个连接，这无疑就降低了系统的可用性。比如每个节点不发生故障的概率是99.9%，那么经过5个节点之后，这个请求不发生故障的概率就会降为99.9%的5次方，约等于99.5%。而且数据在不同节点的传输中也会影响效率（序列化与反序列化）。

因此要保证请求路径尽可能的短。

4.依赖要尽可能的少

这里说的依赖是说的强依赖，也就是说我们处理请求的这个服务强依赖于其他服务，这就造成了整个系统的可用性的降低。

我们可以根据业务逻辑来将不同的服务独立开来，并设置分级。上级服务尽量减少对下级服务的强依赖，这样可以防止重要的服务被相对而言不重要的服务拉胯。

5.不要有单点

这个就很好理解了，单点的弊端大家都清楚，如果真有一个服务是单点的，那么如果这个服务发生异常或者宕掉了，那么无疑会引发大范围的事故。

而且我们现在大部分都是分布式系统了，也基本不存在单点这个问题了。

而这4要1不要也是要根据实际情况来进行取舍的，有时候会针对具体情况进行定制化。

二、数据

并发量大，瞬时流量大是秒杀的一个特点。那么瞬时的数据读写操作也会相应的大幅度增加。

在处理数据的时候，我们要分为读，写两个操作来进行不同的处理。

1.并发读

要解决并发读的问题，就需要先进行判断出来秒杀时或者说是高并发时，用户要读取的数据到底是什么，

也就是一个热点数据的发现行为。

我们可以通过多种方式来进行热点数据的发现。

①采用类似强制性手段，谁要进行秒杀活动，或者什么商品要参加秒杀，这些都需要卖家进行报名，这样我们就可以在业务层面首先确定哪些商品可能会成为热点数据。

②采用数据分析，提前分析出来哪些商品在这次活动中受欢迎的概率大一些，可以进行针对性的热点处理。

③采用动态热点分析，我们可以构建一个异步系统，在整个秒杀活动的链路上，提前进行热点数据的分析，比如说采集首页上面的搜索量或者商品的热度值，可以传入到分析模块进行分析，分析出结果后通知我们下游服务，下游服务针对性的进行热点缓存。

通过发现热点数据，并将之放入到缓存当中，可以提高高并发情况下的读请求的效率。

针对热点数据，我们要分情况的对其进行优化、限制、隔离。

优化的情况我们需要考虑这个热点数据的组成，看看他是否实现了动静分离，如果有的话，可以将静态资源长期缓存，而动态资源我们可以设置一个较短的过期时间，因为我们知道，热度也是会不断变化的。这里可以使用LRU淘汰算法（淘汰掉热度最低的数据）来淘汰掉原来的数据。

限制其实也是对服务的一种保护，我们可以通过多种方式实现将热点数据单独的限制在一个处理队列里面，这样就可以防止大量访问热点数据的请求过来访问热点，抢占了所有的资源，而导致访问其他数据的请求阻塞。

隔离其实就是将整个秒杀模块独立出来。包括服务及数据库。将秒杀模块独立出来的话，相关的请求就会进入我们给他专门搭建的集群中，从而跟普通请求分离开来，而且数据库的隔离，也可以减少其他模块因为秒杀活动开始之后造成的数据库的访问压力。

目的都是为了防止因为较小的数据（请求）影响全部的数据（请求）。

其实说到并发读，大多数人想的都是利用缓存来进行，但是其实还有一种思路就是采用服务器应用层的LocalCache（可以使用ConcurrentHashMap），可以用来存放一些经常被读取但不经常修改的数据。因为单台缓存机器最大也就是职称30W/S的请求，而直接使用Java 的LocalCache的话就直接看服务器的性能了。

2.并发写

而秒杀模块的并发写操作其实就是一个下订单（一般的话，秒杀的商品是不会放入购物车中）。这就涉及到了我们秒杀活动中不可避免的一个库存的问题。

什么时候锁库存，如何锁库存，如何防止超卖这也是秒杀的难点。

一般而言，现在就锁库存有三种方式：

①下订单锁库存

②付款之后锁库存

③预扣库存

①下订单锁库存：用户下了订单之后，就进行库存中减去订单中的商品数量。这种方式是实现锁库存的最简单的方法也是最安全的方法，一定不会发生超卖情况。但是，你要知道，并不是下了订单就要付款的，正常用户的话是会正常购买，但是如果有其他竞争对手进行恶意竞争，就可能会导致大量下订单又不付款的情况。当然针对这个情况我们也有相应的风控进行前序的风控判断，但是无疑也是增大了业务的复杂度。

②付款之后锁库存：用户下了订单之后，并不会去扣减库存，而是在用户支付成功之后再去扣减库存。这样可能出现的问题就是用户在下了单之后，商品卖光了，那么用户就不能去继续进行支付了。甚至在高并发情况下，会出现商品超卖现象。

③预扣库存：这种的实现就会稍微麻烦一些，用户下单之后，我们会为用户创建一个过期时间相对较短的订单（根据不同的业务来），在订单未过期期间，我们为其保留一个库存，过期之后，我们将库存释放，其他用户可以继续购买。用户在下单之后去付款的时候，我们再次进行校验状态，包括库存数量，秒杀商品的状态以及限购量等，如果通过之后就可以付款成功。如果库存不足的话，就提示用户秒杀失败。

虽然第三种看起来很美好，但是实际上还是没有解决问题，因为你依然为用户保留了一个过期时间，如果存在恶意攻击的话，依然可以在这个过期时间内刷空你的库存。

那么实际应用中，那种方案更好呢？

在实际中，因为下单减库存比预扣库存以及付款之后锁库存的实现以及逻辑更加简单，所以采用这种方式的比较多。同时为了防止超卖，一种是在应用程序中通过事务来判断，即保证减后库存不能为负数，否则就回滚；另一种办法是直接设置数据库的字段数据为无符号整数，这样减后库存字段值小于零时会直接执行 SQL 语句来报错；再有一种就是使用 CASE WHEN 判断语句，例如这样的 SQL 语句：

UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END

还有一种方法就是，库存量就是一个热点数据。我们要提前将之放入到缓存当中，进行缓存预热。

而针对这个库存量，其实读的时候是不需要强一致性的，只有写的时候是要求强一致性的。

我们可以将库存的写操作直接放在缓存中进行操作，当然这个缓存必须要支持持久化，我使用的是redis，我们可以采用redis 的list数据结构（队列），来左放右取，从而防止超卖。

当然这是一种非常简单的秒杀才会使用到的。如果你的业务逻辑很复杂，也就是扣除库存的逻辑很复杂的话，那我们就不能在缓存中进行处理了，而是要对数据库进行操作了。这个时候就需要上锁及事务啦。

因为前面讲过，我们可以讲秒杀系统单独提出来，然后数据库也是单独的，那么就不存在因为秒杀的请求而阻塞其他正常请求数据库的问题了。但是这还是没有解决Mysql 的行级锁的问题，这个时候我们就需要在应用层面或者数据库层面进行排队处理了。

①应用层面：我们可以以商品id为标识，进行分队列操作，这样就可以避免大量请求去访问同一行造成的请求阻塞，同时也可以控制链接到数据库的连接数，防止过度占用资源。

②数据库层面：应用层面只能保证单台服务器内的请求排队了，对于集群而言，效果不大。这时候就需要第三方补丁来帮忙实现数据库层面的排队了。推荐alisql。