秒杀架构设计

前言

最近在部门内部分享了原来在电商业务做秒杀活动的整体思路，大家对这次分享反馈还不错，所以我就简单整理了一下，分享给大家参考参考

业务介绍

什么是秒杀？通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动

比如说京东秒杀，就是一种定时定量秒杀，在规定的时间内，无论商品是否秒杀完毕，该场次的秒杀活动都会结束。这种秒杀，对时间不是特别严格，只要下手快点，秒中的概率还是比较大的。

淘宝以前就做过一元抢购，一般都是限量 1 件商品，同时价格低到「令人发齿」，这种秒杀一般都在开始时间 1 到 3 秒内就已经抢光了，参与这个秒杀一般都是看运气的，不必太强求

业务特点

瞬时并发量大

秒杀时会有大量用户在同一时间进行抢购，瞬时并发访问量突增 10 倍，甚至 100 倍以上都有。

库存量少

一般秒杀活动商品量很少，这就导致了只有极少量用户能成功购买到。

业务简单

流程比较简单，一般都是下订单、扣库存、支付订单

技术难点

现有业务的冲击

秒杀是营销活动中的一种，如果和其他营销活动应用部署在同一服务器上，肯定会对现有其他活动造成冲击，极端情况下可能导致整个电商系统服务宕机

直接下订单

下单页面是一个正常的 URL 地址，需要控制在秒杀开始前，不能下订单，只能浏览对应活动商品的信息。简单来说，需要 Disable 订单按钮

页面流量突增

秒杀活动开始前后，会有很多用户请求对应商品页面，会造成后台服务器的流量突增，同时对应的网络带宽增加，需要控制商品页面的流量不会对后台服务器、DB、Redis 等组件的造成过大的压力

架构设计思想

限流

由于活动库存量一般都是很少，对应的只有少部分用户才能秒杀成功。所以我们需要限制大部分用户流量，只准少量用户流量进入后端服务器

削峰

秒杀开始的那一瞬间，会有大量用户冲击进来，所以在开始时候会有一个瞬间流量峰值。如何把瞬间的流量峰值变得更平缓，是能否成功设计好秒杀系统的关键因素。实现流量削峰填谷，一般的采用缓存和 MQ 中间件来解决

异步

秒杀其实可以当做高并发系统来处理，在这个时候，可以考虑从业务上做兼容，将同步的业务，设计成异步处理的任务，提高网站的整体可用性

缓存

秒杀系统的瓶颈主要体现在下订单、扣减库存流程中。在这些流程中主要用到 OLTP 的数据库，类似 MySQL、SQLServer、Oracle。由于数据库底层采用 B+ 树的储存结构，对应我们随机写入与读取的效率，相对较低。如果我们把部分业务逻辑迁移到内存的缓存或者 Redis 中，会极大的提高并发效率

整体架构

客户端优化

客户端优化主要有两个问题

秒杀页面

秒杀活动开始前，其实就有很多用户访问该页面了。如果这个页面的一些资源，比如 CSS、JS、图片、商品详情等，都访问后端服务器，甚至 DB 的话，服务肯定会出现不可用的情况。所以一般我们会把这个页面整体进行静态化，并将页面静态化之后的页面分发到 CDN 边缘节点上，起到压力分散的作用

防止提前下单

防止提前下单主要是在静态化页面中加入一个 JS 文件引用，该 JS 文件包含活动是否开始的标记以及开始时的动态下单页面的 URL 参数。同时，这个 JS 文件是不会被 CDN 系统缓存的，会一直请求后端服务的，所以这个 JS 文件一定要很小。当活动快开始的时候（比如提前），通过后台接口修改这个 JS 文件使之生效

API 接入层优化

客户端优化，对于不是搞计算机方面的用户还是可以防止住的。但是稍有一定网络基础的用户就起不到作用了，因此服务端也需要加些对应控制，不能信任客户端的任何操作。一般控制分为 2 大类

限制用户维度访问频率

针对同一个用户（ Userid 维度），做页面级别缓存，单元时间内的请求，统一走缓存，返回同一个页面

限制商品维度访问频率

大量请求同时间段查询同一个商品时，可以做页面级别缓存，不管下回是谁来访问，只要是这个页面就直接返回

SOA 服务层优化

上面两层只能限制异常用户访问，如果秒杀活动运营的比较好，很多用户都参加了，就会造成系统压力过大甚至宕机，因此需要后端流量控制

对于后端系统的控制可以通过消息队列、异步处理、提高并发等方式解决。对于超过系统水位线的请求，直接采取 「Fail-Fast」原则，拒绝掉

秒杀整体流程图

秒杀系统核心在于层层过滤，逐渐递减瞬时访问压力，减少最终对数据库的冲击。通过上面流程图就会发现压力最大的地方在哪里？

MQ 排队服务，只要 MQ 排队服务顶住，后面下订单与扣减库存的压力都是自己能控制的，根据数据库的压力，可以定制化创建订单消费者的数量，避免出现消费者数据量过多，导致数据库压力过大或者直接宕机。

库存服务专门为秒杀的商品提供库存管理，实现提前锁定库存，避免超卖的现象。同时，通过超时处理任务发现已抢到商品，但未付款的订单，并在规定付款时间后，处理这些订单，将恢复订单商品对应的库存量

总结

核心思想：层层过滤

• 尽量将请求拦截在上游，降低下游的压力
• 充分利用缓存与消息队列，提高请求处理速度以及削峰填谷的作用

参考

©著作权归作者所有：来自51CTO博客作者曹林华的原创作品，如需转载，请注明出处，否则将追究法律责任

• 前言
• 业务介绍
• 业务特点
• 瞬时并发量大
• 库存量少
• 业务简单
• 技术难点
• 现有业务的冲击
• 直接下订单
• 页面流量突增
• 架构设计思想
• 限流
• 削峰
• 异步
• 缓存
• 整体架构
• 客户端优化
• API 接入层优化
• SOA 服务层优化
• 秒杀整体流程图
• 总结
• 参考

扫一扫,领取大礼包

---

Page 2

• 序：微服务技术架构以及大数据治理实战

  微服务架构微服务的诞生并非偶然，它是在互联网高速发展，技术日新月异的变化以及传统架构无法适应快速变化等多重因素的推动下诞生的产物。

• 1-1 微服务下的技术选型

  这篇文章我们就来了解下在微服务架构下如何进行技术选型

• 1-2 Spring Boot 对 Web 开发的支持

  在我们开发的项目中，几乎每个项目都需要对外提供接口交互，也就意味着我们开发过的项目中，绝大多数都是 Web 相关项目，Spring Boot 对 Web 开发支持度非常完善，几乎涉及 Web 开发的方方面面。

• 1-3 使用 Spring Boot 操作关系数据库方案

  Spring Boot 更推荐使用 Jpa 的形式去操作数据库，其中 Spring Boot 依赖 Hibernate 实现了 Spring Data JPA ;而 Mybatis 官网主动对 Spring Boot 进行了集成，因此使用 Spring Boot 非常容易、简单操作关系数据库。

• 1-4 Spring Boot 和 Nosql 数据库的使用

  NoSQL 最常见的解释是 “non-relational”，“Not Only SQL” 也被很多人接受。 是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL 的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

• 1-5 Spring Boot 下的（分布式）事务解决方案

  微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇，很多互联网行业巨头、开源社区等都开始了微服务的实践。系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变得非常突出，所以在采用微服务架构时需要考虑分布式事务的解决方案。

• 1-6 Spring Boot Starter 的秘密

  Spring Boot Starters 是一个依赖描述符的集合，你可以将它包含进项目中，这样添加依赖就非常方便。你可以获取所有 Spring 及相关技术的一站式服务，而不需要翻阅示例代码，拷贝粘贴大量的依赖描述符。例如，如果你想使用 Spring 和 JPA 进行数据库访问，只需要在项目中包含`spring-boot-starter-data-jpa`依赖，然后你就可以开始了。所以我们可以看出 Spring Boot 通过不同的 Starter 来支持各种中间件的使用。

• 2-1 MongoDB 特点、搭建方案介绍

  MongoDB特点、搭建方案介绍MongoDB如今是最流行的Nosql数据库，被广泛应用于各行各业中，很多创业公司数据库选型就直接使用了MongoDB，但对于大部分公司，使用MongoDB的场景是做大规模数据查询和离线分析。MongoDB一经推出就受到广大社区的热爱，可以说是对程序员最友好的一种数据库，今天我们来了解它的特性。MongoDB简介MongoDB（来自于英文单词“Humongous”，

• 2-2 使用 Spring Boot 操作 MongoDB

  Spring Boot 操作数据库的各种 Starters 都继承于 Spring Data, Spring Data 是 Spring 为了简化数据库操作而封装的一个组件包，提供了操作多种数据库的支持，其api简洁，调用方便。

• 2-3 Spring Boot 和 MongoDB 多数据源，混合数据源的使用

  多数据源的使用思路，先封装不同的数据源，然后再将不同的数据注入到对应的 Repository 层中，业务想使用哪个数据源的操作，就把对应的 Repository 层注入到业务中使用即可，我们先来看 MongoDB 多数据源的使用情况。

• 2-4 MongoDB 支持动态 SQL、分页方案

  在互联网企业中往往数据量庞大。分页展示就成为了一种非常好的技术方案，一方面可以减少系统压力，一方面也方便用户去浏览信息。Spirng Boot 结合 MongoDB 有多种分页实现方案，下面我们来分别介绍。

• 2-5 MongoDB 分布式计算 Aggregate VS Mapreduce

  MapReduce 架构是用来解决大数据量的分布式计算问题，然后把计算后的结果放入文件系统或者数据库中。

• 3-1 各类同步技术方案对比、介绍

  在介绍数据分析之前，我们先详解了解下什么是联机事务处理 OLTP 和 联机分析处理 OLAP，以及它们之间的区别。

• 3-2 同步工具 Canal 使用、搭建方案介绍

  对比主流的数据同步方案我们得知，canal 在性能、稳定性、灵活度等方面表现突出，经过大厂的验证并开源可控，是我们的首选。同时 canal 只负责对 Binlog 监听、传输和解析，数据解析后的操作需要我们自己写程序来完成。本节内容给大家介绍 canal 的使用。

• 3-3 使用 Canal 将业务数据从 Mysql 同步到 MongoDB

  今天我们分为两部分来学习 canal 的数据同步，第一部分是通过监听 canal 服务端，实时获取被改动后的数据；第二部分，对变更后的数据进行存储到数据库。

• 3-4 解决后期业务变动导致的数据结构不一致的问题

  在实际的使用中，我们推荐准实时的方式对数据进行清洗和处理，结合上一节内容我们可以借用反射的原理来解决这个问题，当数据同步后，同步去检查是否有根据此表进行数据清洗的流程，如果有在数据同步完成之后直接对数据进行清洗整理。

• 4-1 如何在原有的系统架构上进行微服务架构演进

  大部分企业都有大量遗留的应用系统，因此对需要更快更好地满足业务需求成为迫切任务时，大部分情况下企业不会全新构建一个完整的应用，通常情况下是企业对已有应用进行重构或希望能尽量重用已有代码。

• 4-2 如何在微服务架构中做好部署、监控

  采用微服务架构意味着以更复杂的运维环境为代价，微服务架构组建复杂度远超传统项目，架构体系会对微服务的部署、监控有了更高的要求。就微服务应用平台本身来说，并不依赖 DevOps 和容器云，开发好的部署包可以运行在物理机、虚拟机或者是容器中。

• 4-3 在微服务架构演化过程中的一些经验和教训

  使用传统的整体式架构(Monolithic Architecture)应用开发系统，如 CRM、ERP 等大型应用，随着新需求的不断增加，企业更新和修复大型整体式应用变得越来越困难；随着移动互联网的发展，企业被迫将其应用迁移至现代化 UI 界面架构以便能兼容移动设备，这要求企业能实现应用功能的快速上线。