应用场景

秒杀系统往往应用在电商系统中，比如手机首卖抢购、双十一、火车票放票购票等，有其他场景吗？欢迎各位补充评论。

此类场景下，均是在某一时刻忽然有大量用户访问同一个服务，一般来说，这种情况往往会给服务带了很大的压力，导致服务扛不住，甚至崩溃不能服务的情况。那么秒杀系统应该如何处理这种场景呢？

本质上解决的问题

秒杀服务本质上解决的是高并发的场景下，如何保证服务不被压垮，并且可以持续正常提供服务问题。

设计思路

• 分布式设计

对于业务逻辑复杂一点的服务来说，单台服务器的QPS肯定是不能满足秒杀场景的需求，所以必须引入分布式的架构，可以做到横向扩展的能力，这是在设计之初就应该考虑到的。

• 异步处理架构

异步处理是提高服务QPS承受能力的重要优化点之一，举一个例子，通常来讲NIO的服务器所能承受的QPS要比BIO高出许多，另外，异步处理也可以让模块之间耦合度更松，那么也就更有利于瓶颈的优化，当然这里所说的异步处理架构也不是说就一定使用NIO技术，后面再架构描述中会有对异步处理的介绍。

• 高效数据缓存

高并发必须要有高效的数据读写操作，因此服务必须具备高速的读写数据存储服务。

架构描述

对于高并发系统来说，往往有很多架构方式，这里介绍一种常见的架构方式；这种架构分三部分构成。

1. 请求缓存模块

由于瞬间来了大量的请求，短时间内肯定处理不完，如果要一直保持的连接必然很耗费资源，因此收到请求之后，先不处理，仅仅是做一个记录；比如记录到redis或者kafka等，然后返回给客户端结果，说明请求成功，正在处理，巴拉巴拉之类的。

请求缓存模块功能应尽可能的简单，尽可能承受更高的QPS，功能简单有利于增强高并发处理能力。该模块上线之前一定要做压力测试，比如每秒钟可以处理10w QPS，那么上线之后一定要限定请求的并发数，超过这个并发数之后，可以直接返回失败，这是保证服务不被压垮的关键。

2. 请求处理模块

可以将此模块类比于消费者，去处理请求队列中的请求。

3.结果查询模块

查询请求处理结果。

架构图如下：

大家有什么补充的呢？