如何设计秒杀系统?

秒杀系统是我在面试中问得比较多的,如果说程序 = 算法 +数据结构的话,那么系统 = 服务 + 数据存储。所以系统设计中,我们更多的是围绕服务和数据存储来讨论。

举个简单例子:某年双 11,商家以 4499 的价格上架了某 iphone,比官网价格便宜了 1000 员,库存总数 10 台,运营设置 11/11 00:00 活动生效,一人只能购买 1 台,商品售完为止。

首先梳理下用户端的流程图:

根据九章算法**系统设计 4S 分析法**,**第一步 Scenario 场景。**需要确定设计哪些功能,承受多大的访问量?

这里要知道秒杀系统的常见概念 QPS ( Queries Per Second ),即一秒内可以处理的请求数量。

假如一个服务的 RT ( Response time )是 20ms,则 QPS 为 50 (这里计算的是单机单线程 QPS,如果要计算集群的话,需要考虑集群数量和线程数量)。

QPS = 100,用你的笔记本做 Web 服务器足矣。
QPS = 1k,用一台好点的 Web 服务器也差不多了。
QPS = 1m,则需要建设一个 1000 台 Web 服务器的集群。

QPS 和服务器 /数据库之间的关系:

一台服务器承受量约 1k 的 QPS (考虑到逻辑处理时间以及数据库查询的瓶颈)
一台 SQL Database 承受量约 1k 的 QPS(如果 JOIN 和 INDEX query 比较多的话,这个值会更小)
一台 NoSQL Database ( Casscandra )承受量约 10k 的 QPS
一台 NoSQL Database ( Memcached )承受量约 1M 的 QPS

第二步,Service 服务

服务可以认为是逻辑处理的整合。对于同一类问题的逻辑处理归并在一个服务中,整个系统可以细分为若干个小的服务。

这里秒杀系统服务设计大致如下:

第三步,Storage 存储,数据是如何存储和访问的。为每个服务选择合适的存储结构,然后细化数据表结构。这个例子中,秒杀系统数据库设计如下

于是我们可以得到秒杀活动中,数据库之间的关系如图所示

好了,接下来是重点。我们先基于数据库 Mysql 来扣库存

update stock set count = count - 1 where product_id = xxxx and count > 0

那么问题来了,秒杀系统一定会有并发( concurrent )问题,怎么办?

这里一般有两种解决方案:乐观锁( Optimistic Lock )和悲观锁( Pessimistic Lock )。

悲观锁的流程如下:

在对于数据一致性要求非常高的场景中,一般用悲观锁。

乐观锁流程如下:

可以看到悲观锁的问题是会占用大量的线程资源,可能导致 mysql 的线程耗尽。而乐观锁在 version 变动频繁的情况下则不适用,所以秒杀系统就不太适合用乐观锁,因为 version (库存)变化太快了。

另外可以再看下 Redis 下的秒杀系统数据库设计。

几个关于秒杀系统中 Redis 的常见问题:

什么时候把库存写入到 Redis ?
秒杀活动创建 /维护时写入 Redis 。
如何保证活动数据库和库存数据一致?
可以使用分布式事务或消息队列。

**分布式事务:**保证多个数据库的操作同时成功或者同时失败。对强一致性有要求的业务场景可以考虑使用分布式事务,比如银行转账

**消息队列:**基于生产者 /消费者模型的组件,一般实现异步任务(非实时处理)时会引入消息队列。消息队列的好处是任务可以慢慢处理,不必同步处理等着响应结果。目前主流的消息队列有 RocketMQ 、Kafka 等。使用场景除了异步任务之外,一般还用于失败的情况下重试处理,重复消费直到消费成功。

下单减库存 /支付减库存?
下单锁定库存,支付减库存。

如何防止商品被超卖?
把库存数据放入到缓存中,利用缓存的原子特性保证同时只有一个线程操作库存。

库存写回数据库的时机?
采用定时任务同步 Redis 的数据写回数据库。

最后,4S 分析法的第四步,Scale 扩展。对于秒杀系统来说,就是高并发场景下如何优化系统。

另外关于 4S 分析法以及系统设计面试的各种问题,在《系统架构设计 System Design 2020 版》中也都有讲到,同时新版课程中我们邀请了 3 位一线 IT 大厂面试官,讲解当前国内热门系统设计问题,**前两节限免开放**中,有兴趣的同学可以来看看。

首节免费试听课随时可试听,第二节免费试听课明天早上 9:30-11:30 惊喜开播,戳我即可免费报名试听

免费试听内容如下:

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注