【20210827】【系统设计】“秒杀系统”架构设计分析

时间：2021年08月27日

作者：小蒋聊技术

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

在互联网高速发展的今天，大家已经习惯了一个又一个的便捷互联网服务在改变着我们的生活。出门买东西不用带钱，直接扫个码支付。饿了直接手机下个单，外卖就有人直接送上门。家里缺的日用品，电商直接买，不但东西品类多，价格还实惠。这些互联网服务真是棒！

所以，这几年互联网服务的用户数是越来越多。也正是因为这越来越多的用户，使得这些便捷的互联网服务的压力变得也越来越大，高并发的场景几乎无处不在。互联网公司为了让用户能有一个优质的使用体验，解决高并发的问题就显得尤为突出了。小蒋今天准备和朋友们，一起来看看高并发下的系统架构设计，以及在真实的业务中遇到的各种常见问题。

说到高并发，我们常见的“秒杀活动”和“抢购活动”是两个比较典型的业务场景。小蒋接下来和大家一起来分析看看，电商系统中的秒杀业务究竟是怎么做的。

秒杀业务特点

说到“秒杀”，咱得先来说这个业务特点。那什么是秒杀，秒杀就是一件商品购买的人数远远大于这个商品的库存。这个商品开卖的瞬间就被抢购一空。每年的618、双11、iphone新产品发布等业务场景，这就是典型的秒杀。

咱举例说明：

618期间，某电商平台促销，领劵叠加方式可降价1400元买到一个全新的iphone 12，这个电商平台以远低于市场平均的价格在销售。那朋友们想一想，接下来会发生什么事呢？

在开始领券的时候，大量用户会在同一时间同时抢购，访问量和并发量会瞬间激增。
因为优惠券库存量远远小于想要领取的用户数，所以系统呈现读多写少的业务特点。
因为优惠力度大，电商平台在前期进行了大幅推广，优惠券瞬间售空。

秒杀业务对架构设计上的挑战

“秒杀”从营销层面上来说是一个赔本赚吆喝的活动。以极低的价格吸引用户的流量，再通过部分流量的转化变为二次销售或再次销售。

对现有业务以及相关基础设施的冲击

秒杀活动具有时间短，但访问量特别大的特点。如果不在架构上进行提前防范，那原有系统将会直接面临流量上的巨大冲击，与黑客的DDos(分布式拒绝服务)攻击非常相似，稍有不慎可能会导致整个网站瘫痪。

解决策略：“隔离”。

方法：

案例中的某电商平台选择了：

业务隔离，优惠券业务与商品下单从业务上就剥离了。即使优惠券业务因为某些问题导致系统宕机，后果就是用户领不到优惠券了，依旧不会影响正常的商品购买，大不了秒杀活动不做了呗。别因为秒杀活动，直接导致电商平台整个系统宕机，影响到了正常业务的开展。
技术隔离，秒杀业务的相关系统完全独立部署，例如，Web服务署隔离，域名隔离，中间件集群隔离，例如Redis、MQ、Zookeeper等独立部署。确保秒杀业务的大流量不会干扰其他业务的正常运行。

大流量下高并发对服务（Web服务、API服务、中间件服务）和数据库（DB）的冲击

要怎么理解业务和服务呢，业务和服务究竟有什么区别呢？这个事情咱先要搞清楚，然后小蒋再往下说。

咱举例说明，电商的核心交易部分中业务有：

购物车业务
下单业务
付款业务
库存业务
优惠业务
地址业务
订单管理业务
退款业务
……

把每一个业务组合起来形成一个复杂而又完整的电商系统。

但是每一个业务背后，其实有很多技术的服务在支撑。例如上面例子里的优惠券业务。

支撑优惠券业务的服务有：

优惠券显示服务（Nginx、Apache、Caddy、……）
网关服务（Zuul、Tyk、Kong、……）
优惠券查询服务（Dubbo、Spring Cloud、Srping boot、……）
数据库服务（MySql、Oracle、TIDB）
基础中间件服务（Redis、MQ、Zookeeper、……）
大数据服务（Hadoop、Spark、Hive、……）
……

这些服务在支持着一个业务正常的运行。

咱们聊完了业务和服务的区别后，回来继续说秒杀。

用户在“秒杀”活动开始之前的3分钟左右，就已经开始不停的进行刷新，谁都不会想错过如此低廉价格的秒杀活动。无论是网页端还是手机App端，由于不停刷新而带来的大流量就像洪水袭击一般冲击着我们的各种服务集群。

解决策略：堵不如疏

如洪水一般大的流量，我们的堤坝再高，硬件系统再强也很难抵御住如此大的冲击。与其被动防御，不如主动进攻，从源头开始治理这些流量，把这如洪水般的流量遏制在萌芽中。把这些巨大的流量，分而治之。用合理的成本对应瞬时飙高的峰值请求，且确保秒杀活动整个过程中的系统容量的可伸缩性、用户响应时间的稳定性、以及外部依赖系统出现问题时的高可用性。

方法：

系统静态化、建立缓存体系、内容CDN化。

通过将页面中的内容按业务进行分类分区，按商家、用户、时间、地域等信息维度分析，提取页面内容中相对公共，没有依赖关系的那部分数据，且变化频率低的内容，生成静态化基础内容。静态化内容URL地址是确定的，这样可以直接存入缓存。其他动态内容通过异步接口调用填充。拿优惠券为例，可静态化的基础数据有：优惠券标题、优惠券详情信息、领取规则等。这些信息均可以静态化，直接存入缓存。其他个性化内容，如当前登录用户是否可领取优惠券，库存，已领取数量等动态信息则通过异步接口调用方式填充至静态化页面。

这些静态化的内容被存入了各种类型的缓存，如应用服务缓存、Web服务缓存、CDN缓存、客户端浏览器缓存，它们分别承载着不同的使命。这样我们就通过了架构的升级改造，就把流量分而治之，从根本上提高了系统效率，降低了每个系统的并发访问压力。而不只是仅仅依靠单纯的水平扩容机制，不断通过堆叠硬件的方式，去解决秒杀带来的井喷式的流量增长。

上面的解决方案听起来似乎不太难，但是有很多落地的细节是需要工时的，这个过程背后的开发工作量却不小。

静态化架构的升级工作，天猫商城是从2011年开始进行规划，2013年底彻底完成的。小蒋当时也身处电商行业，与天猫商城是有技术交流的。天猫历时了3年才彻底做到了商城系统CDN化。又通过了很长一段时间的系统调优，才有效解决了缓存命中率、流量自然分布、系统扩容简化、用户端响应速度可控等关键问题。

互联网公司解决问题的技术方案可能千差万别的，但是遇到的难点和挑战通常是相似的，所以解决问题的思路也是大致相似的。大家要抓住问题的核心，别去纠结技术细节上的差别。

另外，秒杀系统中还会经常遇到各问题和系统Bug，比如商品超卖、缓存数量与数据库库存不一致、数据的高可用性等。这些常见的问题和解决方案小蒋会在下一次的内容中与大家分享并一起探讨。

年龄的增长不可怕，可怕的是从未成长。

感谢大家支持小蒋，小蒋想和大家共同成长，谢谢。

音频地址：https://www.ximalaya.com/keji/51588599/448399382