如果让你设计一个秒杀系统，你会如何设计？

以前做的电商系统，很久了，前几天有朋友问当初设计，就找文章大家一起学习下；

大型促销活动带来的是流量暴涨，在高访问量的冲击下，电商系统会受到以下挑战：瞬间访问量可能是平时的几十倍；网络带宽被占满，用户响应很慢；机器负载高甚至宕机；数据库压力过大导致服务不可用,各家电商峰值系统的架构设计，由于电商规模、商业模式以及技术选型的不同，其技术方案多彩多样、百花齐放，着实令人兴奋，全面展现了互联网技术开放和创新的特征。下面从这些架构设计方案中，抽象和总结出其共性相通的核心思路，进行一些概述。核心思路集中表现为：采用分而治之的思想，大系统小做，小系统大做。浓缩一下就是三个字：快、稳、炫

快——天下武功，唯快不破

快的目标是确保用户端快速流畅的体验。概括来说，可以通过以下技术手段实现快的目标。

对前端页面的处理

·         将有效期较长的静态页面通过CDN（Content Delivery Network，内容分发网络）缓存到离用户最近的服务节点上。

·         将有效期较短或者需要对失效时间做最大限度控制的静态页面，通过类似于Memcache的高速缓存系统或类似于Squid的反向代理系统缓存在服务端。

·         将混合型页面（如商品单页）进行动静分离，静态数据（如商品介绍等）缓存在本地，动态数据（如可用库存和促销价格等）异步进行加载。

对后端数据的处理

·         数据库SQL慢查询优化。例如，重构相关索引，对where子句进行优化等。

·         数据库读写分离。例如，MySQL的Master/Slave结构。

·         数据库分库分表。这是减轻单个数据库服务器压力的有效手段，不过同时也会带来系统的复杂性，是鱼和熊掌之间的关系。

对网络传输的处理

·         执行负载均衡，第四层交换按实现分类，分为硬件实现和软件实现。通过硬件实现一般都由专业的硬件厂商作为商业解决方案提供，如F5等，这些产品非常昂贵，但能够提供非常优秀的性能和很灵活的管理能力。通过软件实现，如LVS等，虽然性能比专业硬件稍差，但软件实现配置起来更灵活。

稳——不管风吹浪打，胜似闲庭信步

稳的目标是确保系统端稳定可靠的服务。无论在任何情况下，都要做到尽可能不宕机、不出错。要做到这一点，可以在以下几个方面做文章。

系统解耦

拆分业务模块和功能模块，使得每个模块都做到高度内聚，然后用SOA，通过严格定义模块之间的服务接口，做到模块间的松散耦合。在一个模块发生问题时尽可能不影响其他模块的执行，尤其不能影响关键业务的执行。同时，可以对单个模块进行横向扩展，尤其是对关键的业务模块，以确保关键业务一定不能受影响。需要注意的是，模块划分的粒度应进行权衡，过细的粒度虽然可以带来更多的灵活性，但也会带来编程的复杂性。

有损服务

根据CAP（Consistency一致性，Availability可用性，Partition Tolerance分区容忍性）理论，三者不可得兼。对于电商平台，其中多数应用并不需要很强的一致性，因此合理的方式是用牺牲部分一致性来换取较高的可用性。有损服务（服务降级）就是一种提高系统稳定性和可用性的有效实践。在电商系统中，要优先保证类目浏览、产品单页和订单流程能够执行。

数据库减负

我们知道数据库是所有节点中最不容易扩展的，复杂的SQL查询条件会导致数据库负担过重，此时可用增加应用计算中间服务器的方式，通过高效简洁的SQL查询，应用计算中间服务器一次性地从数据库中取出最小全集的数据行，然后在内存中利用算法剔除冗余数据，以应用算法的复杂度换数据库负担的方式。

炫——运筹于帷幄之中，决胜于千里之外

炫的目标是确保业务端实时高效的调度。从日志收集和实时计算入手，通过对用户行为数据的可视化（图1），及时发现问题和洞察商机，调度应用系统，对用户多样化和个性化的需求进行智能引导。

现有业务的冲击

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

直接下订单

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

页面流量突增

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

限流

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

削峰

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

异步

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

缓存

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

整体架构

整个秒杀方案就介绍这么多，其实整个的思路还是比较简单的，也没有特别复杂的地方，对于大部分公司的高并发场景还是适用的，并且比较容易实施上线，该方案对于我们当时每秒几万的并发场景是能够扛住的，但是对于像小米、12306这些在高峰时动不动几十万用户并发的场景，使用这样的方案可能用户体验方面和系统服务方面就会存在一些问题了，对于每秒几十万并发的场景我们一般除了会在技术层面进行优化，更多的会通过其他一些业务手段来进行交易分流来分散整体的高并发访问，秒杀方案就介绍到这里，具体的实现这里就不写了，我相信跟着上面介绍的思路很容易就能将代码写出来。