对于一个秒杀系统来说，瞬时的大量请求会对后台服务造成冲击，需要保证服务的可用性以及业务的正确性。

设计了一个高并发高可用的系统简要流程架构如下图:

1.将商品(或券)的信息等静态数据放到cdn节点，实现动静分离

2.业务请求和业务处理之间使用MQ对请求进行削峰

3.读写分离：对于逻辑复杂(用户验证，风控管理，行为分析)的系统，可以将读写部署两套服务进行分离

4.使用缓存：

• 像库存这种信息无法放到静态页面，为了应对大并发读问题，可以在服务端做本地缓存用于读取，一般缓存时间设置为数秒，缓存失效时(最好在失效前一两秒)重新拉取redis中的库存信息。防止超买问题由扣减行为保证，因此即使和缓存不一致，读本地缓存也不会导致超卖，读场景一般允许脏数据情况。

• 高并发时，大量的mysql操作会有很大性能问题，因此使用redis集群作为缓存进行读取。

5.防止缓存雪崩：

• 减少缓存渗透：可以在服务中进行布隆过滤，可以将不存在的商品或券访问在服务端过滤掉；或者对缓存中没有的数据key置为null并设置较短的过期时间，优点是简单易操作，缺点要增加大量的null key，增大了与mysql的不一致性，需要消息机制和mysql保持同步

• 限流：对key的操作加锁排队(利用setnx进行分布式锁)，即同时只允许一个线程访问。

• 防止缓存同时失效：设置key的过期时间时，采用固定时间+随机时间的方法，可以有效防止缓存同时过期引起雪崩的问题

• 增加二级缓存: A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。

6.合理设置redis中的key，使其均匀的分布到各个节点，防止大量请求访问到少量节点的热点问题，而且可以减少单个节点宕机造成的影响。

7.由于商品或券具有独立性， 每个商品或券分配一个独有id，可以根据id范围划分到各个服务集群中，服务在访问对应范围的的redis缓存，这样可以大大增加访问的并发性。实现方式一个是在web服务中将id路由到对应的消息队列topic中，另一个是在消息队列后部署消息路由集群，相对来说方案一更好，因为方案而增加了链路长度和故障点。

8.在7的基础上，为了进一步提升性能防止少量热点数据影响全量数据的操作性能，可在服务中统计热点数据(比如LRU)，并将热点数据独立存放到一个集群中去，这样可以将热点数据和其它数据隔离开来。当然这样会增加热点数据迁移的工作，增加了系统的复杂性。

什么是秒杀？

“秒杀”是商家在特定时间点进行促销的一种运营手段，体现在系统层面，是指一个Web系统，在一秒钟收到数以万计的用户请求，来抢购数量有限的促销产品。本质上，秒杀系统就是一个“三高”系统，即高并发、高性能、高可用的分布式系统。本文主要从“高并发”的角度，来看看需要解决的主要问题。

秒杀需要处理并发读，并发写。“并发读”需要通过各种手段减少用户到服务端来读数据，而“并发写”主要需要保证数据的正确性，确保大流量下数据一致。

秒杀系统关注三方面

下面以一个秒杀系统的例子，来看看一个秒杀系统主要关注的三方面问题。

一、高并发访问

秒杀前用户不断刷新页面查看，来获得购买按钮，抢购时集中点击并发购买，核心是对系统数据的高并发读访问，可以通过如下手段进行防护。

访问拦截：从浏览器/反向代理/Web层/服务层/数据层多层拦截流量，尽量把访问拦截在离用户更近的层，减少对后台的压力；

分流：主要通过分布式集群技术，多台机器处理，提高并发能力；

动静分离：将动态数据和静态数据尽量分离，并通过缓存和CDN等技术对数据读取进行加速；

二、数据正确性

秒杀伴随这一系列业务流程，包括浏览商品、进入抢购页、购买、扣减库存、支付。其中并发写主要与扣减库存有关，要保证数据的正确性，防止超卖发生。大概的解决方法有：

减库存：事务判断，热点商品放到单独的热点库，增加并发锁

热点：对核心热点数据进行实时分析，并在系统中进行优化或隔离

异步化：是指把购买请求的接受和处理异步化。购买请求先放到队列中，这个过程非常高效，返回客户信息。

限流降级：请求限流，控制系统的访问；对服务的下游依赖进行降级，保证核心链路

三、防作弊

抢购还需要保证公平性，方舟如购票插件购买火车票、黄牛党等。在技术角度，大概方法有:

答题：为了增加购买的复杂度；延缓请求。

Cache校验：处理用户购买请求时校验缓存中是否已记录此商品的购买。

秒杀系统设计原则

1、前台请求数尽量少

前台请求会增加浏览器的负担，尽量简化或合并页面大小（CSS/JS，图片等），去掉页面装饰；减少DNCS解析

2、后台数据尽量少

后台数据会增加网络传输，压缩和字符编码，消耗CPU。需要梳理后台依赖的数据和服务，关注序列化/反序列化方式，减少不必要的数据交互

3、调用路径要尽量短

分布式调用错综复杂，需要尽量缩短调用链路；减少第三方依赖，尽量弱依赖，并做好应用分级

4、尽量不要有单点

高可用和稳定性角度，消除单点；服务无状态化，解藕服务状态和机器，如机器配置动态化；有状态的存储，通过冗余备份提高可用性。

1.将商品(或券)的信息等静态数据放到cdn节点，实现动静分离

2.业务请求和业务处理之间使用MQ对请求进行削峰

3.读写分离：对于逻辑复杂(用户验证，风控管理，行为分析)的系统，可以将读写部署两套服务进行分离

4.使用缓存：

像库存这种信息无法放到静态页面，为了应对大并发读问题，可以在服务端做本地缓存用于读取，一般缓存时间设置为数秒，缓存失效时(最好在失效前一两秒)重新拉取redis中的库存信息。防止超买问题由扣减行为保证，因此即使和缓存不一致，读本地缓存也不会导致超卖，读场景一般允许脏数据情况。

高并发时，大量的mysql操作会有很大性能问题，因此使用redis集群作为缓存进行读取。

5.防止缓存雪崩：

减少缓存渗透：可以在服务中进行布隆过滤，可以将不存在的商品或券访问在服务端过滤掉；或者对缓存中没有的数据key置为null并设置较短的过期时间，优点是简单易操作，缺点要增加大量的null key，增大了与mysql的不一致性，需要消息机制和mysql保持同步

限流：对key的操作加锁排队(利用setnx进行分布式锁)，即同时只允许一个线程访问。

防止缓存同时失效：设置key的过期时间时，采用固定时间+随机时间的方法，可以有效防止缓存同时过期引起雪崩的问题

增加二级缓存: A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。

6.合理设置redis中的key，使其均匀的分布到各个节点，防止大量请求访问到少量节点的热点问题，而且可以减少单个节点宕机造成的影响。

7.由于商品或券具有独立性， 每个商品或券分配一个独有id，可以根据id范围划分到各个服务集群中，服务在访问对应范围的的redis缓存，这样可以大大增加访问的并发性。实现方式一个是在web服务中将id路由到对应的消息队列topic中，另一个是在消息队列后部署消息路由集群，相对来说方案一更好，因为方案而增加了链路长度和故障点。

8.在7的基础上，为了进一步提升性能防止少量热点数据影响全量数据的操作性能，可在服务中统计热点数据(比如LRU)，并将热点数据独立存放到一个集群中去，这样可以将热点数据和其它数据隔离开来。当然这样会增加热点数据迁移的工作，增加了系统的复杂性。

高并发的接口/系统有一个共同的特性，那就是”快”。 
在系统其它条件既定的情况下，系统处理请求越快，用户得到反馈的时间就越短，单位时间内服务器能够处理请求的数量就会越多。所以”快”几乎可以算是高并发系统的要满足的必要条件，要评估一个系统性能如何，某次优化是否提高系统的容量，”快”是一个很直观的衡量标准。

什么是秒杀？

“秒杀”是商家在特定时间点进行促销的一种运营手段，体现在系统层面，是指一个Web系统，在一秒钟收到数以万计的用户请求，来抢购数量有限的促销产品。本质上，秒杀系统就是一个“三高”系统，即高并发、高性能、高可用的分布式系统。本文主要从“高并发”的角度，来看看需要解决的主要问题。

秒杀需要处理并发读，并发写。“并发读”需要通过各种手段减少用户到服务端来读数据，而“并发写”主要需要保证数据的正确性，确保大流量下数据一致。

秒杀系统关注三方面

下面以一个秒杀系统的例子，来看看一个秒杀系统主要关注的三方面问题。

一、高并发访问

秒杀前用户不断刷新页面查看，来获得购买按钮，抢购时集中点击并发购买，核心是对系统数据的高并发读访问，可以通过如下手段进行防护。

访问拦截：从浏览器/反向代理/Web层/服务层/数据层多层拦截流量，尽量把访问拦截在离用户更近的层，减少对后台的压力；

分流：主要通过分布式集群技术，多台机器处理，提高并发能力；

动静分离：将动态数据和静态数据尽量分离，并通过缓存和CDN等技术对数据读取进行加速；

二、数据正确性

秒杀伴随这一系列业务流程，包括浏览商品、进入抢购页、购买、扣减库存、支付。其中并发写主要与扣减库存有关，要保证数据的正确性，防止超卖发生。大概的解决方法有：

减库存：事务判断，热点商品放到单独的热点库，增加并发锁

热点：对核心热点数据进行实时分析，并在系统中进行优化或隔离

异步化：是指把购买请求的接受和处理异步化。购买请求先放到队列中，这个过程非常高效，返回客户信息。

限流降级：请求限流，控制系统的访问；对服务的下游依赖进行降级，保证核心链路

三、防作弊

抢购还需要保证公平性，方舟如购票插件购买火车票、黄牛党等。在技术角度，大概方法有:

答题：为了增加购买的复杂度；延缓请求。

Cache校验：处理用户购买请求时校验缓存中是否已记录此商品的购买。

秒杀系统设计原则

1、前台请求数尽量少

前台请求会增加浏览器的负担，尽量简化或合并页面大小（CSS/JS，图片等），去掉页面装饰；减少DNCS解析

2、后台数据尽量少

后台数据会增加网络传输，压缩和字符编码，消耗CPU。需要梳理后台依赖的数据和服务，关注序列化/反序列化方式，减少不必要的数据交互

3、调用路径要尽量短

分布式调用错综复杂，需要尽量缩短调用链路；减少第三方依赖，尽量弱依赖，并做好应用分级

4、尽量不要有单点

高可用和稳定性角度，消除单点；服务无状态化，解藕服务状态和机器，如机器配置动态化；有状态的存储，通过冗余备份提高可用性

高并发的接口/系统有一个共同的特性，那就是”快”。 
在系统其它条件既定的情况下，系统处理请求越快，用户得到反馈的时间就越短，单位时间内服务器能够处理请求的数量就会越多。所以”快”几乎可以算是高并发系统的要满足的必要条件，要评估一个系统性能如何，某次优化是否提高系统的容量，”快”是一个很直观的衡量标准。

对于一个秒杀系统来说，瞬时的大量请求会对后台服务造成冲击，需要保证服务的可用性以及业务的正确性。