区块链技术博客
www.b2bchain.cn

「系统设计面试题」如何设计一个秒杀系统?求职学习资料

本文介绍了「系统设计面试题」如何设计一个秒杀系统?求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

大家好,我是 Guide!

今天这篇文章咱们就开始从后端的角度来谈谈:“如何设计秒杀系统?”。

在你看这篇文章之前,我想说的是系统设计没有一个标准答案,你需要结合自己的过往经验来回答,我这篇文章也是简单说说自己的看法。

下面是正文!

设计秒杀系统之前,我们首先需要对秒杀系统有一个清晰的认识。

秒杀系统主要为商品(往往是爆款商品)秒杀活动提供支持,这个秒杀活动会限制商品的个数以及秒杀持续时间。

「系统设计面试题」如何设计一个秒杀系统?

为什么秒杀系统的设计是一个难点呢? 是因为它的业务复杂么? 当然不是!

秒杀系统的业务逻辑非常简单,一般就是下订单减库存,难点在于我们如何保障秒杀能够顺利进行。

「系统设计面试题」如何设计一个秒杀系统?

  • 秒杀开始的时候,会有大量用户同时参与进来,因此秒杀系统一定要满足 高并发高性能
  • 为了保证秒杀整个流程的顺利进行,整个秒杀系统必须要满足 高可用
  • 除此之外,由于商品的库存有限,在面对大量订单的情况下,一定不能超卖,我们还需要保证 一致性

很多小伙伴可能不太了解当代三高互联网架构:高并发、高性能、高可用。

我这里简单解释一下:高并发简单来说就是能够同时处理很多用户请求。高性能简单来说就是处理用户的请求速度要快。高可用简单来说就是我们的系统要在趋近 100% 的时间内都能正确提供服务。

知道了秒杀系统的特点之后,我们站在技术层面来思考一下:“设计秒杀系统的过程中需要重点关注哪些问题”。

  1. 参与秒杀的商品属于热点数据,我们该如何处理热点数据?
  2. 商品的库存有限,在面对大量订单的情况下,如何解决超卖的问题?
  3. 如果系统用了消息队列,如何保证消息队列不丢失消息?
  4. 如何保证秒杀系统的高可用?
  5. 如何对项目进行压测?有哪些工具?
  6. ……

好的,废话不多说!正式开始!

高并发&高性能

热点数据处理

何为热点数据? 热点数据指的就是某一时间段内被大量访问的数据,比如爆款商品的数据、新闻热点。

为什么要关注热点数据? 热点数据可能仅仅占据系统所有数据的 0.1% ,但是其访问量可能是比其他所有数据之和还要多。不重点处理热点数据,势必会给系统资源消耗带来严峻的挑战。

热点数据的分类? 根据热点数据的特点,我们通常将其分为两类:

  • 静态热点数据 :可以提前预测到的热点数据比如要秒杀的商品。
  • 动态热点数据 : 不能够提前预测到的热点数据,需要通过一些手段动态检测系统运行情况产生。

另外,处理热点数据的问题的关键就在于 我们如何找到这些热点数据(或者说热 key),然后将它们存在 jvm 内存里。 对于并发量非常一般的系统直接将热点数据存放进缓存比如 Redis 中就可以了,不过像淘宝、京东这种级别的并发量,如果把某些热点数据放在 Redis 中,直接可能就将整个 Redis 集群给干掉了。

如何检测热点数据?

我了解到的是市面上也有一些类似的中间件,比如京东零售的 hotkey 就是一款专门用于检测热点数据的中间件,它可以毫秒级探测热点数据,毫秒级推送至服务器集群内存。相关阅读:京东毫秒级热 key 探测框架设计与实践,已完美支撑 618 大促 。

另外,我们平时使用 Redis 做缓存比较多,关于如何快速定位 Redis 热点数据,可以看下如何快速定位 Redis 热 key这篇文章。

「系统设计面试题」如何设计一个秒杀系统?

如何处理热点数据? 热点数据一定要放在缓存中,并且最好可以写入到 jvm 内存一份(多级缓存),并设置个过期时间。需要注意写入到 jvm 的热点数据不宜过多,避免内存占用过大,一定要设置到淘汰策略。

为什么还要放在 jvm 内存一份? 因为放在 jvm 内存中的数据访问速度是最快的,不存在什么网络开销。

流量削峰

消息队列

秒杀开始之后的流量不是很大,我处理不了嘛!那我就先把这些请求放到消息队列中去。然后,咱后端服务再慢慢根据自己的能力去消费这些消息,这样就避免直接把后端服务打垮掉。

「系统设计面试题」如何设计一个秒杀系统?

消息队列是一种非常实用的流量削峰手段。只要是涉及到流量削峰,那必然不可缺少消息队列。

回答问题/验证码

我们可以在用户发起秒杀请求之前让其进行答题或者输入验证码。

这种方式一方面可以避免用户请求过于集中,另一方面可以有效解决用户使用脚本作弊。

回答问题/验证码这一步建议除了对答案的正确性做校验,还需要对用户的提交时间做校验,比如提交时间过短(<1s)的话,大概就是使用脚本来处理的。

高可用

集群化

如果我们想要保证系统中某一个组件的高可用,往往需要搭建集群来避免单点风险,比如说 Nginx 集群、Kafka 集群、Redis 集群。

我们拿 Redis 来举例说明。如果我们需要保证 Redis 高可用的话,该怎么做呢?

你直接通过 Redis replication(异步复制) 搞个一主(master)多从(slave)来提高可用性和读吞吐量,slave 的多少取决于你的读吞吐量。

「系统设计面试题」如何设计一个秒杀系统?

img

这样的方式有一个问题:一旦 master 宕机,slave 晋升成 master,同时需要修改应用方的主节点地址,还需要命令所有从节点去复制新的主节点,整个过程需要人工干预。

不过,这个问题我们可以通过 Sentinel(哨兵) 来解决。Redis Sentinel 是 Redis 官方推荐的高可用性(HA)解决方案。

Sentinel 是 Redis 的一种运行模式 ,它主要的作用就是对 Redis 运行节点进行监控。当 master 节点出现故障的时候, Sentinel 会帮助我们实现故障转移,确保整个 Redis 系统的可用性。整个过程完全自动,不需要人工介入!

「系统设计面试题」如何设计一个秒杀系统?

img

Sentinel 也是一个 Redis 进程,只是不对外提供读写服务,通常哨兵要配置成单数。

限流

限流是从用户访问压力的角度来考虑如何应对系统故障。限流为了对服务端的接口接受请求的频率进行限制,防止服务挂掉。

🌰 举个例子:我们的秒杀接口一秒只能处理 10w 个请求,结果秒杀活动刚开始一下子来了 15w 个请求。这肯定不行啊!我们只能通过限流把 5w 个请求给拦截住,不然系统直接就给整挂掉了!

限流的话可以直接用 Redis 来做(建议基于 Lua 脚本),也可以使用现成的流量控制组件比如 Sentinel 、Hystrix 、Resilience4J 。

Hystrix 是 Netflix 开源的熔断降级组件。

Sentinel 是阿里巴巴体提供的面向分布式服务架构的流量控制组件,经历了淘宝近10年双11(11.11)购物节的所有核心场景(比如秒杀活动)的考验。

Sentinel 主要以流量为切入点,提供 流量控制熔断降级系统自适应保护等功能来保护系统的稳定性和可用性。

「系统设计面试题」如何设计一个秒杀系统?

个人比较建议使用 Sentinel ,更新维护频率更高,功能更强大,并且生态也更丰富(Sentinel 提供与 Spring Cloud、Dubbo 和 gRPC 等常用框架和库的开箱即用集成, Sentinel 未来还会对更多常用框架进行适配,并且会为 Service Mesh 提供集群流量防护的能力)。

「系统设计面试题」如何设计一个秒杀系统?

排队

你可以把排队看作是限流的一个变种。限流是直接拒绝了用户的请求,而排队则是让用户等待一定的时间(类比现实世界的排队)。

排队虽然没有直接拒绝用户,但用户等了很长时间后进入系统,体验并不一定比限流好。

🌰 举个例子:当请求量达到一个阈值的时候,我们就通知用户让它们排队。等到系统可以继续处理请求之后,再慢慢来处理。

大家好,我是 Guide!

今天这篇文章咱们就开始从后端的角度来谈谈:“如何设计秒杀系统?”。

在你看这篇文章之前,我想说的是系统设计没有一个标准答案,你需要结合自己的过往经验来回答,我这篇文章也是简单说说自己的看法。

下面是正文!

设计秒杀系统之前,我们首先需要对秒杀系统有一个清晰的认识。

秒杀系统主要为商品(往往是爆款商品)秒杀活动提供支持,这个秒杀活动会限制商品的个数以及秒杀持续时间。

「系统设计面试题」如何设计一个秒杀系统?

为什么秒杀系统的设计是一个难点呢? 是因为它的业务复杂么? 当然不是!

秒杀系统的业务逻辑非常简单,一般就是下订单减库存,难点在于我们如何保障秒杀能够顺利进行。

「系统设计面试题」如何设计一个秒杀系统?

  • 秒杀开始的时候,会有大量用户同时参与进来,因此秒杀系统一定要满足 高并发高性能
  • 为了保证秒杀整个流程的顺利进行,整个秒杀系统必须要满足 高可用
  • 除此之外,由于商品的库存有限,在面对大量订单的情况下,一定不能超卖,我们还需要保证 一致性

很多小伙伴可能不太了解当代三高互联网架构:高并发、高性能、高可用。

我这里简单解释一下:高并发简单来说就是能够同时处理很多用户请求。高性能简单来说就是处理用户的请求速度要快。高可用简单来说就是我们的系统要在趋近 100% 的时间内都能正确提供服务。

知道了秒杀系统的特点之后,我们站在技术层面来思考一下:“设计秒杀系统的过程中需要重点关注哪些问题”。

  1. 参与秒杀的商品属于热点数据,我们该如何处理热点数据?
  2. 商品的库存有限,在面对大量订单的情况下,如何解决超卖的问题?
  3. 如果系统用了消息队列,如何保证消息队列不丢失消息?
  4. 如何保证秒杀系统的高可用?
  5. 如何对项目进行压测?有哪些工具?
  6. ……

好的,废话不多说!正式开始!

高并发&高性能

热点数据处理

何为热点数据? 热点数据指的就是某一时间段内被大量访问的数据,比如爆款商品的数据、新闻热点。

为什么要关注热点数据? 热点数据可能仅仅占据系统所有数据的 0.1% ,但是其访问量可能是比其他所有数据之和还要多。不重点处理热点数据,势必会给系统资源消耗带来严峻的挑战。

热点数据的分类? 根据热点数据的特点,我们通常将其分为两类:

  • 静态热点数据 :可以提前预测到的热点数据比如要秒杀的商品。
  • 动态热点数据 : 不能够提前预测到的热点数据,需要通过一些手段动态检测系统运行情况产生。

另外,处理热点数据的问题的关键就在于 我们如何找到这些热点数据(或者说热 key),然后将它们存在 jvm 内存里。 对于并发量非常一般的系统直接将热点数据存放进缓存比如 Redis 中就可以了,不过像淘宝、京东这种级别的并发量,如果把某些热点数据放在 Redis 中,直接可能就将整个 Redis 集群给干掉了。

如何检测热点数据?

我了解到的是市面上也有一些类似的中间件,比如京东零售的 hotkey 就是一款专门用于检测热点数据的中间件,它可以毫秒级探测热点数据,毫秒级推送至服务器集群内存。相关阅读:京东毫秒级热 key 探测框架设计与实践,已完美支撑 618 大促 。

另外,我们平时使用 Redis 做缓存比较多,关于如何快速定位 Redis 热点数据,可以看下如何快速定位 Redis 热 key这篇文章。

「系统设计面试题」如何设计一个秒杀系统?

如何处理热点数据? 热点数据一定要放在缓存中,并且最好可以写入到 jvm 内存一份(多级缓存),并设置个过期时间。需要注意写入到 jvm 的热点数据不宜过多,避免内存占用过大,一定要设置到淘汰策略。

为什么还要放在 jvm 内存一份? 因为放在 jvm 内存中的数据访问速度是最快的,不存在什么网络开销。

流量削峰

消息队列

秒杀开始之后的流量不是很大,我处理不了嘛!那我就先把这些请求放到消息队列中去。然后,咱后端服务再慢慢根据自己的能力去消费这些消息,这样就避免直接把后端服务打垮掉。

「系统设计面试题」如何设计一个秒杀系统?

消息队列是一种非常实用的流量削峰手段。只要是涉及到流量削峰,那必然不可缺少消息队列。

回答问题/验证码

我们可以在用户发起秒杀请求之前让其进行答题或者输入验证码。

这种方式一方面可以避免用户请求过于集中,另一方面可以有效解决用户使用脚本作弊。

回答问题/验证码这一步建议除了对答案的正确性做校验,还需要对用户的提交时间做校验,比如提交时间过短(<1s)的话,大概就是使用脚本来处理的。

高可用

集群化

如果我们想要保证系统中某一个组件的高可用,往往需要搭建集群来避免单点风险,比如说 Nginx 集群、Kafka 集群、Redis 集群。

我们拿 Redis 来举例说明。如果我们需要保证 Redis 高可用的话,该怎么做呢?

你直接通过 Redis replication(异步复制) 搞个一主(master)多从(slave)来提高可用性和读吞吐量,slave 的多少取决于你的读吞吐量。

「系统设计面试题」如何设计一个秒杀系统?

img

这样的方式有一个问题:一旦 master 宕机,slave 晋升成 master,同时需要修改应用方的主节点地址,还需要命令所有从节点去复制新的主节点,整个过程需要人工干预。

不过,这个问题我们可以通过 Sentinel(哨兵) 来解决。Redis Sentinel 是 Redis 官方推荐的高可用性(HA)解决方案。

Sentinel 是 Redis 的一种运行模式 ,它主要的作用就是对 Redis 运行节点进行监控。当 master 节点出现故障的时候, Sentinel 会帮助我们实现故障转移,确保整个 Redis 系统的可用性。整个过程完全自动,不需要人工介入!

「系统设计面试题」如何设计一个秒杀系统?

img

Sentinel 也是一个 Redis 进程,只是不对外提供读写服务,通常哨兵要配置成单数。

限流

限流是从用户访问压力的角度来考虑如何应对系统故障。限流为了对服务端的接口接受请求的频率进行限制,防止服务挂掉。

🌰 举个例子:我们的秒杀接口一秒只能处理 10w 个请求,结果秒杀活动刚开始一下子来了 15w 个请求。这肯定不行啊!我们只能通过限流把 5w 个请求给拦截住,不然系统直接就给整挂掉了!

限流的话可以直接用 Redis 来做(建议基于 Lua 脚本),也可以使用现成的流量控制组件比如 Sentinel 、Hystrix 、Resilience4J 。

Hystrix 是 Netflix 开源的熔断降级组件。

Sentinel 是阿里巴巴体提供的面向分布式服务架构的流量控制组件,经历了淘宝近10年双11(11.11)购物节的所有核心场景(比如秒杀活动)的考验。

Sentinel 主要以流量为切入点,提供 流量控制熔断降级系统自适应保护等功能来保护系统的稳定性和可用性。

「系统设计面试题」如何设计一个秒杀系统?

个人比较建议使用 Sentinel ,更新维护频率更高,功能更强大,并且生态也更丰富(Sentinel 提供与 Spring Cloud、Dubbo 和 gRPC 等常用框架和库的开箱即用集成, Sentinel 未来还会对更多常用框架进行适配,并且会为 Service Mesh 提供集群流量防护的能力)。

「系统设计面试题」如何设计一个秒杀系统?

排队

你可以把排队看作是限流的一个变种。限流是直接拒绝了用户的请求,而排队则是让用户等待一定的时间(类比现实世界的排队)。

排队虽然没有直接拒绝用户,但用户等了很长时间后进入系统,体验并不一定比限流好。

🌰 举个例子:当请求量达到一个阈值的时候,我们就通知用户让它们排队。等到系统可以继续处理请求之后,再慢慢来处理。

大家好,我是 Guide!

今天这篇文章咱们就开始从后端的角度来谈谈:“如何设计秒杀系统?”。

在你看这篇文章之前,我想说的是系统设计没有一个标准答案,你需要结合自己的过往经验来回答,我这篇文章也是简单说说自己的看法。

下面是正文!

设计秒杀系统之前,我们首先需要对秒杀系统有一个清晰的认识。

秒杀系统主要为商品(往往是爆款商品)秒杀活动提供支持,这个秒杀活动会限制商品的个数以及秒杀持续时间。

「系统设计面试题」如何设计一个秒杀系统?

为什么秒杀系统的设计是一个难点呢? 是因为它的业务复杂么? 当然不是!

秒杀系统的业务逻辑非常简单,一般就是下订单减库存,难点在于我们如何保障秒杀能够顺利进行。

「系统设计面试题」如何设计一个秒杀系统?

  • 秒杀开始的时候,会有大量用户同时参与进来,因此秒杀系统一定要满足 高并发高性能
  • 为了保证秒杀整个流程的顺利进行,整个秒杀系统必须要满足 高可用
  • 除此之外,由于商品的库存有限,在面对大量订单的情况下,一定不能超卖,我们还需要保证 一致性

很多小伙伴可能不太了解当代三高互联网架构:高并发、高性能、高可用。

我这里简单解释一下:高并发简单来说就是能够同时处理很多用户请求。高性能简单来说就是处理用户的请求速度要快。高可用简单来说就是我们的系统要在趋近 100% 的时间内都能正确提供服务。

知道了秒杀系统的特点之后,我们站在技术层面来思考一下:“设计秒杀系统的过程中需要重点关注哪些问题”。

  1. 参与秒杀的商品属于热点数据,我们该如何处理热点数据?
  2. 商品的库存有限,在面对大量订单的情况下,如何解决超卖的问题?
  3. 如果系统用了消息队列,如何保证消息队列不丢失消息?
  4. 如何保证秒杀系统的高可用?
  5. 如何对项目进行压测?有哪些工具?
  6. ……

好的,废话不多说!正式开始!

高并发&高性能

热点数据处理

何为热点数据? 热点数据指的就是某一时间段内被大量访问的数据,比如爆款商品的数据、新闻热点。

为什么要关注热点数据? 热点数据可能仅仅占据系统所有数据的 0.1% ,但是其访问量可能是比其他所有数据之和还要多。不重点处理热点数据,势必会给系统资源消耗带来严峻的挑战。

热点数据的分类? 根据热点数据的特点,我们通常将其分为两类:

  • 静态热点数据 :可以提前预测到的热点数据比如要秒杀的商品。
  • 动态热点数据 : 不能够提前预测到的热点数据,需要通过一些手段动态检测系统运行情况产生。

另外,处理热点数据的问题的关键就在于 我们如何找到这些热点数据(或者说热 key),然后将它们存在 jvm 内存里。 对于并发量非常一般的系统直接将热点数据存放进缓存比如 Redis 中就可以了,不过像淘宝、京东这种级别的并发量,如果把某些热点数据放在 Redis 中,直接可能就将整个 Redis 集群给干掉了。

如何检测热点数据?

我了解到的是市面上也有一些类似的中间件,比如京东零售的 hotkey 就是一款专门用于检测热点数据的中间件,它可以毫秒级探测热点数据,毫秒级推送至服务器集群内存。相关阅读:京东毫秒级热 key 探测框架设计与实践,已完美支撑 618 大促 。

另外,我们平时使用 Redis 做缓存比较多,关于如何快速定位 Redis 热点数据,可以看下如何快速定位 Redis 热 key这篇文章。

「系统设计面试题」如何设计一个秒杀系统?

如何处理热点数据? 热点数据一定要放在缓存中,并且最好可以写入到 jvm 内存一份(多级缓存),并设置个过期时间。需要注意写入到 jvm 的热点数据不宜过多,避免内存占用过大,一定要设置到淘汰策略。

为什么还要放在 jvm 内存一份? 因为放在 jvm 内存中的数据访问速度是最快的,不存在什么网络开销。

流量削峰

消息队列

秒杀开始之后的流量不是很大,我处理不了嘛!那我就先把这些请求放到消息队列中去。然后,咱后端服务再慢慢根据自己的能力去消费这些消息,这样就避免直接把后端服务打垮掉。

「系统设计面试题」如何设计一个秒杀系统?

消息队列是一种非常实用的流量削峰手段。只要是涉及到流量削峰,那必然不可缺少消息队列。

回答问题/验证码

我们可以在用户发起秒杀请求之前让其进行答题或者输入验证码。

这种方式一方面可以避免用户请求过于集中,另一方面可以有效解决用户使用脚本作弊。

回答问题/验证码这一步建议除了对答案的正确性做校验,还需要对用户的提交时间做校验,比如提交时间过短(<1s)的话,大概就是使用脚本来处理的。

高可用

集群化

如果我们想要保证系统中某一个组件的高可用,往往需要搭建集群来避免单点风险,比如说 Nginx 集群、Kafka 集群、Redis 集群。

我们拿 Redis 来举例说明。如果我们需要保证 Redis 高可用的话,该怎么做呢?

你直接通过 Redis replication(异步复制) 搞个一主(master)多从(slave)来提高可用性和读吞吐量,slave 的多少取决于你的读吞吐量。

「系统设计面试题」如何设计一个秒杀系统?

img

这样的方式有一个问题:一旦 master 宕机,slave 晋升成 master,同时需要修改应用方的主节点地址,还需要命令所有从节点去复制新的主节点,整个过程需要人工干预。

不过,这个问题我们可以通过 Sentinel(哨兵) 来解决。Redis Sentinel 是 Redis 官方推荐的高可用性(HA)解决方案。

Sentinel 是 Redis 的一种运行模式 ,它主要的作用就是对 Redis 运行节点进行监控。当 master 节点出现故障的时候, Sentinel 会帮助我们实现故障转移,确保整个 Redis 系统的可用性。整个过程完全自动,不需要人工介入!

「系统设计面试题」如何设计一个秒杀系统?

img

Sentinel 也是一个 Redis 进程,只是不对外提供读写服务,通常哨兵要配置成单数。

限流

限流是从用户访问压力的角度来考虑如何应对系统故障。限流为了对服务端的接口接受请求的频率进行限制,防止服务挂掉。

🌰 举个例子:我们的秒杀接口一秒只能处理 10w 个请求,结果秒杀活动刚开始一下子来了 15w 个请求。这肯定不行啊!我们只能通过限流把 5w 个请求给拦截住,不然系统直接就给整挂掉了!

限流的话可以直接用 Redis 来做(建议基于 Lua 脚本),也可以使用现成的流量控制组件比如 Sentinel 、Hystrix 、Resilience4J 。

Hystrix 是 Netflix 开源的熔断降级组件。

Sentinel 是阿里巴巴体提供的面向分布式服务架构的流量控制组件,经历了淘宝近10年双11(11.11)购物节的所有核心场景(比如秒杀活动)的考验。

Sentinel 主要以流量为切入点,提供 流量控制熔断降级系统自适应保护等功能来保护系统的稳定性和可用性。

「系统设计面试题」如何设计一个秒杀系统?

个人比较建议使用 Sentinel ,更新维护频率更高,功能更强大,并且生态也更丰富(Sentinel 提供与 Spring Cloud、Dubbo 和 gRPC 等常用框架和库的开箱即用集成, Sentinel 未来还会对更多常用框架进行适配,并且会为 Service Mesh 提供集群流量防护的能力)。

「系统设计面试题」如何设计一个秒杀系统?

排队

你可以把排队看作是限流的一个变种。限流是直接拒绝了用户的请求,而排队则是让用户等待一定的时间(类比现实世界的排队)。

排队虽然没有直接拒绝用户,但用户等了很长时间后进入系统,体验并不一定比限流好。

🌰 举个例子:当请求量达到一个阈值的时候,我们就通知用户让它们排队。等到系统可以继续处理请求之后,再慢慢来处理。

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » 「系统设计面试题」如何设计一个秒杀系统?求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们