文章插图



图2 秒答题页面
其实增加答题还有一个重要的功能，就是把峰值的下单请求给拉长了，从以前的1s之内延长到2~10s左右，请求峰值基于时间分片了，这个时间的分片对服务端处理并发非常重要，会减轻很大压力，另外由于请求的先后，靠后的请求自然也没有库存了，也根本到不了最后的下单步骤，所以真正的并发写就非常有限了 。其实这种设计思路目前也非常普遍，如支付宝的“咻一咻”已及微信的摇一摇 。
除了在前端通过答题在用户端进行流量削峰外，在服务端一般通过锁或者队列来控制瞬间请求 。
数据分层校验



文章插图



图3 分层校验
对大流量系统的数据做分层校验也是最重要的设计原则，所谓分层校验就是对大量的请求做成“漏斗”式设计，如图3所示：在不同层次尽可能把无效的请求过滤，“漏斗”的最末端才是有效的请求，要达到这个效果必须对数据做分层的校验，下面是一些原则：
先做数据的动静分离
将90%的数据缓存在客户端浏览器
将动态请求的读数据Cache在Web端
对读数据不做强一致性校验
对写数据进行基于时间的合理分片
对写请求做限流保护
对写数据进行强一致性校验
秒杀系统正是按照这个原则设计的系统架构，如图4所示 。



文章插图



图4 秒杀系统分层架构
把大量静态不需要检验的数据放在离用户最近的地方；在前端读系统中检验一些基本信息，如用户是否具有秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束等；在写数据系统中再校验一些如是否是非法请求，营销等价物是否充足（淘金币等），写的数据一致性如检查库存是否还有等；最后在数据库层保证数据最终准确性，如库存不能减为负数 。
实时热点发现
其实秒杀系统本质是还是一个数据读的热点问题，而且是最简单一种，因为在文提到通过业务隔离，我们已能提前识别出这些热点数据，我们可以提前做一些保护，提前识别的热点数据处理起来还相对简单，比如分析历史成交记录发现哪些商品比较热门，分析用户的购物车记录也可以发现那些商品可能会比较好卖，这些都是可以提前分析出来的热点 。比较困难的是那种我们提前发现不了突然成为热点的商品成为热点，这种就要通过实时热点数据分析了，目前我们设计可以在3s内发现交易链路上的实时热点数据，然后根据实时发现的热点数据每个系统做实时保护 。具体实现如下：
构建一个异步的可以收集交易链路上各个中间件产品如Tengine、Tair缓存、HSF等本身的统计的热点key（Tengine和Tair缓存等中间件产品本身已经有热点统计模块） 。
建立一个热点上报和可以按照需求订阅的热点服务的下发规范，主要目的是通过交易链路上各个系统（详情、购物车、交易、优惠、库存、物流）访问的时间差，把上游已经发现的热点能够透传给下游系统，提前做好保护 。比如大促高峰期详情系统是最早知道的，在统计接入层上Tengine模块统计的热点URL 。
将上游的系统收集到热点数据发送到热点服务台上，然后下游系统如交易系统就会知道哪些商品被频繁调用，然后做热点保护 。如图5所示 。

• 拼多多物流助手记录怎么删除？怎么使用？
• 粉丝抽奖小活动小助手 粉丝抽奖小助手入口
• bt游戏助手 Bt手机游戏
• 我叫mt叉叉助手 我叫mt助手easy
• 秒杀活动是什么意思 秒杀什么意思?
• pp助手安卓版 pp下载手机版下载
• 如何进入淘宝一元秒杀 淘宝1元秒杀技巧
• 淘宝秒杀助手 天天秒杀 淘宝
• 抢淘宝秒杀神器 淘宝抢购秒杀神器
• cf活动助手一键领取手机版,一键领取活动助手下载