秒杀问题
今天去面试，面试官问了一个秒杀问题。我当时脑子一片空白，纯靠条件反射说了一个傻逼的答案。
在回程的路上，我骑着电驴还在想着这个事情，思路突然就打开了·····我真傻，真的，真傻。
现在先把能想到的东西记录下。
问题描述
秒杀问题常见于电商平台到点抢购东西，也有其他场景，比如抢票占座等等。从单个请求看整个流程的话，
就是客户发起请求，之后服务端处理并持久化请求，这么一个简单过程。秒杀有个特点就是短时间内有大量的请求进来，
如果处理不好，会造成不好的后果。
整体而言，这是一个开放性问题。即使没有相关工作经验，也是有东西可以扯扯的。下面我就凭着感觉先扯一扯。
问题分析
在真正施工之前，我们作为开发，需要跟产品详细了解下需求，并做数据预估，之后才能制定方案。
整个问题的解法跟预期用户规模有很大关系。比如：
- 预期有几百个人去秒杀，那很可能不需要做任何开发工作就可以抗住压力。当然，稳妥起见，还是要做一下压测，去了解一下当前系统能够承受的压力边界在哪里。
- 预期有几千上万人去秒杀，那我们时是否可以变通一下业务流程？比如，把秒杀改成预约。改成预约之后，整个事情就被转化成了一个批处理问题。
- 如果不能变通，或者预期有更多的人去秒杀，我们就只能硬着头皮上了。
从单个请求上来说，就是客户从客户端发起请求，服务端处理请求并持久化结果，这么一个过程。有一些环节，我们可以做一些工作来抗住压力，这些环节包括：
- 客户端发送请求到服务端的环节
- 网关层路由请求到指定服务器的环节
- 秒杀服务器处理请求的环节
- 查询数据和持久化数据的环节
现在我们要
硬着头皮上
首先，我们需要
明确一些底线要求
比如：
- 秒杀期间不能影响其他业务进行。比如：
- 不能把常规的业务服务搞挂
- 不能把过多的事务直接打到数据库，导致数据库被搞挂掉
- 秒杀不能把用户的钱搞没了，还是没地方查的那种。
我们需要协商，划定红线。如果没人协商，就自己调研一下有哪些红线。
了解当前系统的压力上限
动手之前，需要做几轮压测了解系统的瓶颈在什么地方。比如：
- 当前的数据库配置，可以支持多少 tps 而不影响其他业务进行
- 是否可以增加服务使用的 cpu、内存数量，增加服务实例的数量，提高 tps，能提高到什么程度
根据压测结果，我们发现只需要增加服务使用的机器配置，或者增加服务的数量，就可以抗住压力，那就简单地临时加机器就行。能用钱解决的事情，就用钱解决。
只靠简单的加机器不能够抗住压力，就像需要做额外的开发准备。
了解用户的操作路径
- 秒杀发生在那些页面？
- 这些页面有哪些操作？
- 特别是，用户秒杀失败后，可能会如何重试？
根据用户的操作路径，我们可以预测
- 哪些接口会是热点接口
- 哪些数据可以用缓存临时应付用户，以便在不损失用户体验的情况下，缓解系统压力
- 哪些数据必须动态更新，有没有变通的方式来缓解读取动态数据导致的压力
- 用户失败后会重试，是否可以在客户端引导用户增加重试的时间间隔来缓解系统压力
之后，就可以操刀了。
大致方案
客户端发送请求到服务端的环节
- 是否可以随机丢掉部分用户的请求，来缓解服务器的秒杀请求的压力。比如前 20 秒有 20% 的概率丢掉请求，之后不再丢请求。当然，具体比例最后由产品决定，或者后端研发计算后决定。
- 用户可能提前进入页面等待秒杀。前端是否可以缓存一些数据，以减少不太重要的资源带来的数据访问压力。
- 用户免不了重试。是否可以通过提供良好的用户体验，在用户重试时，适当拉长重试时间间隔，来缓解服务器压力，同时环节用户焦虑情绪。
- 是否可以要求用户在指定客户端秒杀，以增加秒杀过程的可控性。
网关层路由请求到指定服务器的环节
- 确保网关可以抗住压力。
- 网关层通过配置路由规则，将请求路由到指定的服务器。
秒杀服务器处理请求的环节
-
确定是否提供专门的服务器来处理秒杀。如果需要，就申请专用于秒杀的服务器。然后在网关层把秒杀请求路由到秒杀服务器。以确保秒杀服务器被打挂之后不影响其他业务。
-
确定是否要随机丢掉部分的请求，因为丢掉部分请求后，客户会重试。秒杀，就总有人抢不到。所以可以尝试丢掉一定比例的请求。最好还是前端来做，前端做的话，甚至能缓解网关层压力。
-
确定是把请求送入队列，还是使用令牌桶来限制 tps。
- 如果选择把请求送入队列，好处是先到先得，坏处是排队时间可能较长，用户提交请求后需要等待，用户可能会频繁刷新查询结果的接口。
- 如果选择使用令牌桶，好处用户一旦秒杀成功，就可以很快得到结果，坏处是没有秒杀成功的用户会不断重试。
具体方案需要根据预期用户数量，库存数量来决定。比如，我们有 1 万件库存，系统可以承受 1000 tps，那么使用队列就足够，用户最多只需要等 10 秒钟就可以知道结果。
如果有 10 万件库存，请求进入队列后可能需要等好几分钟，这个时候就需要做权衡了。令牌桶的话，建议使用 in-memory 令牌桶，而非分布式令牌桶。
每个服务实例中的令牌桶发放令牌的速度，可以根据预先分配的服务实例数来决定。
查询数据和持久化数据的环节
- 确定是否需要单独的数据库用来应付秒杀。如果需要，就申请专用于秒杀的数据库实例。以确保数据库被打挂之后不影响其他业务。
- 是否需要用缓存来大致计算库存，以避免这种统计性质的查询打到数据库上。
- 如何避免超售问题，或者说是否允许一定的超售。可能需要设计适当的存储结构和锁策略。比如，每个用户一次只能秒杀一件，和一次可以秒杀多件，是两种不同复杂度的问题。
另外
- 系统设计的时候，如果可以，就尽量拉着同事多来几轮评审。
- 一定要压测，验证系统真的可以抗住预期的压力。