秒杀系统

秒杀系统有以下的难点：

• 良好的体验，不出现404，系统错误，系统超时等错误
• 瞬时高并发流量

下图是一般互联网业务的结构：

用户做一个操作，一般会通过接入层和逻辑层，再到存储层。通过接入层我们把请求的数据量减少，再通过逻辑层我们又减少，这样层层递减，到了存储层时的请求压力就很小了。

秒杀系统是读多写少的情形，我们可以利用缓存。

一般用户秒杀失败，都会进行频繁的重试，这样会加剧后端的压力。重试策略需要确定，比如说我们在前端限制用户在一定秒数之内只能提交一次请求。但是这样的策略只能拦住普通的用户，对于程序员来说是拦不住的。

我们就可以在接入层进行拦截，根据uid对请求进行计数和去重。一个uid，在一定秒数之内只能提交一次请求。那对于其他的请求怎么办？缓存，可以通过页面缓存，对于重复的请求返回同一页面，保证用户有良好的体验（没有404），又能保证系统的健壮性（利用好页面缓存，把请求拦截）。但是缓存可能带来数据的不一致，因为站点有多个。但是有些高端程序员，控制肉鸡发请求怎么办（先不考虑实名制的问题）。接入层需要增加机器扩容，有时可能需要抛弃请求，比如说70%的请求直接返回稍后重试。

逻辑层拦截，通过请求队列。利用memcached或redis扛住请求。

当然，有时候也可以进行业务规则上的一些优化。

比如说，分时分段给不同的用户开请求。比如把一次秒杀改成多次，这样避免请求过于集中，不同的用户可以选择不同的时间段来请求（限制每个用户只能购买一次）。

另外，在数据粒度上。我们知道用户，一般只关注有没有，而不关心有多少。所以在数据粒度上，做一个粗粒度的“有”“无”即可。

请求太多，我们可以对用户的请求在前端进行随机丢弃。

用户身份鉴别，没有资格的用户直接返回，已经瓜分的用户返回。

对于单用户/单IP进行频控，防止恶意用户。

秒杀逻辑

总结

主要有以下两点：

• 将请求拦截在系统上层
• 读多写少利用缓存