淘宝应对"双11"的技术架构分析

图7 Prom查询历程

　　图7用一个典型的例子形貌的Prom在提供查询服务时的事情原理，限于篇幅，这里不做详细形貌。值得一提的是，Prom支持的盘算并不仅限于求和SUM运算，统计意义上的常用盘算都是支持的。在现场盘算方面，我们对HBase举行了扩展，Prom要求每个节点返回的数据是已经经由“当地盘算”的局部最优解，最终的全局最优解只是各个节点返回的局部最优解的一个简朴汇总。很显然，这样的设计思绪是要充实使用各个节点的并行盘算能力，而且制止大量明细数据的网络传输开销。

　　用中心层隔离前后端

　　上文提到过，MyFOX和Prom为数据产物的差别需求提供了数据存储和底层查询的解决方案，但随之而来的问题是，种种异构的存储模块给前端产物的使用带来了很大的挑战。而且，前端产物的一个请求所需要的数据往往不行能只从一个模块获取。

　　举个例子，我们要在数据魔方中看昨天做热销的商品，首先从MyFOX中拿到一个热销排行榜的数据，但这里的“商品”只是一个ID，并没有ID所对应的商品形貌、图片等数据。这个时间我们要从淘宝主站提供的接口中去获取这些数据，然后逐一对应到热销排行榜中，最终出现给用户。

图8 glider的手艺架构

　　有履历的读者一定可以想到，从本质上来讲，这就是广义上的异构“表”之间的JOIN操作。那么，谁来卖力这个事情呢？很容易想到，在存储层与前端产物之间增添一其中间层，它卖力各个异构“表”之间的数据JOIN和UNION等盘算，而且隔离前端产物和后端存储，提供统一的数据查询服务。这其中间层就是glider（如图8所示）。

　　缓存是系统化的工程

　　除了起到隔离前后端以及异构“表”之间的数据整合的作用之外，glider的另外一个不容忽视的作用即是缓存治理。上文提到过，在特定的时间段内，我们以为数据产物中的数据是只读的，这是使用缓存来提高性能的理论基础。

　　在图8中我们看到，glider中存在两层缓存，划分是基于各个异构“表”（datasource）的二级缓存和整合之后基于自力请求的一级缓存。除此之外，各个异构“表”内部可能还存在自己的缓存机制。仔细的读者一定注重到了图3中MyFOX的缓存设计，我们没有选择对汇总盘算后的最终效果举行缓存，而是针对每个分片举行缓存，其目的在于提高缓存的掷中率，而且降低数据的冗余度。

　　大量使用缓存的最大问题就是数据一致性问题。怎样保证底层数据的转变在尽可能短的时间内体现给最终用户呢？这一定是一个系统化的工程，尤其对于分层较多的系统来说。

图9 缓存控制系统

　　图9向我们展示了数据魔方在缓存控制方面的设计思绪。用户的请求中一定是带了缓存控制的“下令”的，这包罗URL中的query string，和HTTP头中的“If-None-Match”信息。而且，这个缓存控制“下令”一定会经由层层通报，最终通报到底层存储的异构“表”模块。各异构“表”除了返回各自的数据之外，还会返回各自的数据缓存逾期时间（ttl），而glider最终输出的逾期时间是各个异构“表”逾期时间的最小值。这一逾期时间也一定是从底层存储层层通报，最终通过HTTP头返回给用户浏览器的。

　　缓存系统不得不思量的另一个问题是缓存穿透与失效时的雪崩效应。缓存穿透是指查询一个一定不存在的数据，由于缓存是不掷中时被动写的，而且出于容错思量，若是从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

　　有许多种要领可以有用地解决缓存穿透问题，最常见的则是接纳布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap阻挡掉，从而制止了对底层存储系统的查询压力。在数据魔方里，我们接纳了一个更为简朴粗暴的要领，若是一个查询返回的数据为空（不管是数据不存在，照旧系统故障），我们仍然把这个空效果举行缓存，但它的逾期时间会很短，最长不凌驾五分钟。

 3/4   首页 上一页 1 2 3 4 下一页 尾页