淘宝大秒系统设计详解( 二 ) _淘宝

数据分层校验

文章插图

图3 分层校验
对大流量系统的数据做分层校验也是最重要的设计原则，所谓分层校验就是对大量的请求做成“漏斗”式设计，如图3所示：在不同层次尽可能把无效的请求过滤， “漏斗”的最末端才是有效的请求，要达到这个效果必须对数据做分层的校验，下面是一些原则：

先做数据的动静分离
将90%的数据缓存在客户端浏览器
将动态请求的读数据Cache在Web端
对读数据不做强一致性校验
对写数据进行基于时间的合理分片
对写请求做限流保护
对写数据进行强一致性校验

【淘宝大秒系统设计详解】
秒杀系统正是按照这个原则设计的系统架构，如图4所示。

文章插图

图4 秒杀系统分层架构
把大量静态不需要检验的数据放在离用户最近的地方；在前端读系统中检验一些基本信息，如用户是否具有秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束等；在写数据系统中再校验一些如是否是非法请求，营销等价物是否充足（淘金币等），写的数据一致性如检查库存是否还有等；最后在数据库层保证数据最终准确性，如库存不能减为负数。
实时热点发现其实秒杀系统本质是还是一个数据读的热点问题，而且是最简单一种，因为在文提到通过业务隔离，我们已能提前识别出这些热点数据，我们可以提前做一些保护，提前识别的热点数据处理起来还相对简单，比如分析历史成交记录发现哪些商品比较热门，分析用户的购物车记录也可以发现那些商品可能会比较好卖，这些都是可以提前分析出来的热点。比较困难的是那种我们提前发现不了突然成为热点的商品成为热点，这种就要通过实时热点数据分析了，目前我们设计可以在3s内发现交易链路上的实时热点数据，然后根据实时发现的热点数据每个系统做实时保护。具体实现如下：

构建一个异步的可以收集交易链路上各个中间件产品如Tengine、Tair缓存、HSF等本身的统计的热点key（Tengine和Tair缓存等中间件产品本身已经有热点统计模块）。
建立一个热点上报和可以按照需求订阅的热点服务的下发规范,主要目的是通过交易链路上各个系统（详情、购物车、交易、优惠、库存、物流）访问的时间差，把上游已经发现的热点能够透传给下游系统，提前做好保护。比如大促高峰期详情系统是最早知道的，在统计接入层上Tengine模块统计的热点URL 。
将上游的系统收集到热点数据发送到热点服务台上，然后下游系统如交易系统就会知道哪些商品被频繁调用，然后做热点保护。如图5所示。

文章插图

图5 实时热点数据后台
重要的几个：其中关键部分包括：

这个热点服务后台抓取热点数据日志最好是异步的，一方面便于做到通用性，另一方面不影响业务系统和中间件产品的主流程。
热点服务后台、现有各个中间件和应用在做的没有取代关系，每个中间件和应用还需要保护自己，热点服务后台提供一个收集热点数据提供热点订阅服务的统一规范和工具，便于把各个系统热点数据透明出来。
热点发现要做到实时（3s内）。

关键技术优化点前面介绍了一些如何设计大流量读系统中用到的原则，但是当这些手段都用了，还是有大流量涌入该如何处理呢？秒杀系统要解决几个关键问题。
JAVA处理大并发动态请求优化其实Java和通用的Web服务器相比（Nginx或Apache）在处理大并发HTTP请求时要弱一点，所以一般我们都会对大流量的Web系统做静态化改造，让大部分请求和数据直接在Nginx服务器或者Web代理服务器（Varnish、Squid等）上直接返回（可以减少数据的序列化与反序列化），不要将请求落到Java层上，让Java层只处理很少数据量的动态请求，当然针对这些请求也有一些优化手段可以使用：