网易惠惠购物助手：大数据实时更新框架概述

1、需求是什么？

互联网中的许多应用都有数据实时更新的需求，好比网页搜索如何展现几分钟以前的新闻结果，购物搜索中价格、库存信息的实时更新。在大数据量的状况下，数据如何作到稳定及时的更新？本文以有道购物搜索（惠惠网）价格更新为例，介绍一下数据实时更新系统的服务器端设计方案。

1.1 痛点之一：大数据

无论是网页搜索的时效性内容展现，仍是购物搜索海量商品的价格、库存信息。都是单机较难承受的，同时，大数据对系统的可扩展性，以及运维的稳定性都提出了挑战。网页搜索是几百亿量级，购物搜索是几亿商品量级。

1.2 痛点之二：实时性

若是只是大数据，咱们能够用时间换空间，传统的慢慢的批量更新就好。但不少实际应用，用户须要第一时间掌握最新的消息（网页搜索场景，分钟级别的最新新闻），用户可能几分钟以内就下单，须要了解当前最准确的价格和库存信息（购物场景，热门商品价格和库存变化以后，分钟级别的更新到前台）。实时性不可或缺。

下面具体展现几个使用到实时价格和库存等信息的产品例子。如图 1 所示，购物搜索的详情页中展现了多个来自价格服务器的相关信息。其中用红色椭圆标记的商品价格即为商品的实时价格，用蓝色椭圆标记的价格变化趋势是对商品历史价格的变更趋势归纳，用土黄色椭圆标记的库存状态表示该商城的此商品已经处于缺货状态。经过点击“价格降低”的趋势图标，能够弹出图 2 所示的该商品的价格历史截图。不只购物搜索会使用到实时的价格和库存数据，购物助手在展现比价和价格历史的时候也使用了实时的价格数据，如图 3 所示，蓝色圈起来的是价格历史，红色圈起来的是其它商家的实时价格。

 图1 搜索详情页中价格服务提供的数据截图

图2 索尼HX10数码相机的价格历史截图

图3 购物助手的展现示例

经过以上产品展现，咱们知道在购物搜索与比价等产品中，精准的价格与库存信息直接影响着用户对产品的信赖。所以，这些关键数据的更新速度对整个产品而言就变得相当重要。在传统的搜索引擎系统中，数据的抓取与更新通常由后台驱动完成，即：以固定的时间以必定的频率和策略进行数据抓取，抓到的数据与用户的查询之间有一段“不可接受的”的时间间隔，而这段数据缓存时间每每致使数据过时，使得搜索的结果不够准率。对于购物搜索而言，目前的大型电商网站的商品价格常常会变更，平均每分钟 B2C 价格变化的商品大概在 1500 左右。后台的批量抓取在价格更新方面每每不够及时，为了在任意时刻都可以为用户提供更准确的商品价格，咱们为处理商品价格开发了一个新的服务，价格服务器。

价格服务器这个数据实时更新系统的设计须要解决两个关键的问题：一、大规模数据抓取与更新，知足用户商品检索需求的购物商品数是几亿量级。二、价格、库存数据的实时性。商品价格/库存变化，但愿能作到分钟级别的更新，尤为是用户关注浏览的热门商品。这些大量数据的更新能力，主要取决于咱们自身的抓取能力，同时还依赖于目标电商网站的承受能力。并且价格数据的实时性则关系到用户对产品的信赖度，直接影响着用户在搜索或比价结果中做出的选择。同时，价格的实时性也关系着全部依赖于它的其它服务的实效性，由于在价格更新的同时，也会触发全网比价和降价提醒等服务的数据更新。

2、总体架构设计

价格服务器的总体架构设计包含了两方面的特性：分布式特性和实时特性。下面分别介绍其必要性和具体实现。

2.1 分布式特性

随着电商行业的飞速发展，商品的数量也在不断的快速增长，集中式结构的 可扩展性相对较差，所以整个系统必须使用分布式的体系，将繁杂的不一样的任务分配给若干个独立的系统并行处理，可以极大地提升了系统的性能和可扩展性。

如图4 所示，价格服务器的分布式体系中主要由三种服务构成：任务调度服务器、抓取服务器、结果入库服务器，分别对应图中的 PriceServer、PriceUpdateServer 和 PriceWriteBackServer，这三种服务采用 RPC（远程过程调用）的方式进行相互调用。其中任务调度服务器同时提供对外数据查询的功能。因为系统的分布式特性，这三种服务每一个均可以有多个实例，能够根据系统的实际需求随时进行扩容。其中，最早可能遇到瓶颈的就是抓取服务器，分布式的架构能够简单快捷地经过增长机器来对系统扩容，进而增长系统的抓取能力。分布式特性同时能够提升系统的稳定性，当某一台服务不可用时，同类别的其它服务器仍能够正常运行，减小因为服务宕机致使产品不能使用的几率。

图4 价格服务器的层次结构

2.2 实时特性

整个系统的实时特性主要体如今两个方面：一、数据更新的实时性；二、数据变化后经过其它服务的实时性。

2.2.1 基于查询的实时抓取

在海量的商品面前，因为抓取能力有限，根本没法知足快速地更新全部的商品的价格信息，为了保证用户对于数据高实时性的要求，应该尽量地优先保证热门商品的数据更新，因此实时抓取的商品选择是比较关键的。咱们的系统使用购物助手的浏览记录以及购物搜索的查询记录看成热门商品。具体流程为：用户浏览某商品，购物助手获取该用户所浏览的商品 URL 以及其它商城该商品的 URL 列表发送到任务调度服务器，任务调度服务器根据上一次抓取的价格时间等信息来进行调度，将任务分配至抓取服务器，抓取服务器解析到新的价格后发送到结果入库服务器。结果入库服务器完成数据的更新，并通知其它价格事件监听程序。这就完成了整个基于查询驱动的实时抓取的过程。这种实时抓取策略就叫作“查询驱动抓取”（简称 QTC，Query Triggered Crawling）。

2.2.2 数据变化的实时通知

价格服务器除了实时抓取和管理全部商品的价格以外，还须要向其它服务（如降价提醒、全网比价等）提供价格变化的更新事件。如何使得其它服务能够实时地获得商品的价格变化信息呢？咱们首先介绍一下观察者模式。

观察者模式（也被称为发布/订阅模式）是软件设计模式的一种。在此种模式中，一个目标对象管理全部相依于它的观察者对象，而且在它自己的状态改变时主动发出通知。这一般透过呼叫各观察者所提供的方法来实现。此种模式一般被用来实做事件处理系统。

观察者模式已经在数据变化的实时通知方面被普遍地应用，它使得服务具备高类聚、低耦合的特色。下面来介绍两个使用了相似观察者模式的成熟的系统，分别是 Google的咖啡因（Google Caffeine）索引系统和 Linkedin 的 Databus 数据传输总线。

图5 Google 咖啡因架构

图 5 是 Google 的咖啡因索引架构：Percolator 是基于分布式存储系统 BigTable 的，核心在于实现了对每一个文档的随机访问。Percolator 的观察者模式（observer）能够在底层数据特定列发生更新以后，被系统调用，从而实现上层应用的及时更新。在网页搜索领域里，传统的索引更新方案是基于 MapReduce 和其余批处理系统定时更新的，这使得索引的更新至少须要等待一轮完整的大数据处理流程完成。即便是一轮增量数据处理，相对于实际应用须要，依然是漫长不太可接受的。

再来看另一个架构，前不久，Linkedin 公布了一个其内布使用的 Databus 项目。如图 6 所示，Databus 的主要原理是当任何数据库有更新时，经过分析数据库的更新日志，将全部的数据更新事件传输到 Databus 总线上，进而经过各个其它服务更新数据。数据源发生完成后，Databus 能在微秒级内将事务提交给消费者。同时，消费者使用 Databus 中的服务器端过滤功能，能够只获取本身须要的特定数据。

图6 Linkedin 的 Databus 数据传输总线概要结构

显示易见，Databus 的设计思路与 Percolator 的观察者模式很是类似。所以，咱们在价格服务器中也使用了相似的设计，将实时更新的价格变化事件通知到一系列其它的产品服务中（如降价提醒、全网比价等）。

如图 7 所示，在价格服务器的系统中，结果入库服务器是全部价格数据更新的必经之地，它从数据源获得最新的价格数据，经过对比底层存储中的旧数据，就能够直接获取到全部的价格变化，进而更新数据库中的价格、历史、趋势等信息。它利用观察者模式，将全部的价格变化事件传送到其它监听服务（如降价提醒、全网比价等）。每一个监听服务会根据自身的需求过滤掉没有用的事件，所以像降价提醒这种服务能够实时地提醒用户某个商品的降价消息。

图7 结果入库服务器触发其它服务的数据流程

同时，如图 7 所示，结果入库服务器还会将全部的价格更新信息以日志的形式记录下来，后台的非实时的分析工具经过这些日志构建价格历史、电商价格报表等。

3、数据源

如图 8 所示，价格服务器的价格更新主要来源有三个：一、抓取服务器的实时抓取；二、合做电商主动提供的数据；三、后台定时批量抓取和解析的流程。

图8 商品价格数据来源

这三种数据更新来源，最能保证数据实效性的是抓取服务器的实时抓取，前文已经描述它的工做原理。虽然实时抓取能够最大程度地知足用户查询结果的实效性，可是覆盖率相对较低，所以还须要其它数据源的配合才能提升商品价格更新的覆盖率。和绝大多数搜索引擎相同，购物搜索的后台也会定时批量地抓取大量的商品数据。同时，咱们与一些商家进行了合做，这些商家会定时主动向咱们的系统推送他们最新的商品数据，这些数据也包括价格和库存等信息。有了后台定时批量抓取流程和合做商家的推送数据，几乎就使得绝大多数商品的数据能够获得及时地更新了。

除此以外，还会利用其它服务的日志离线触发价格服务器更新用户感兴趣的商品的价格数据。例如：利用用户订阅的降价提醒商品列表按期更新这些用户感兴趣的商品的价格。又如：全网比价展现了全部最新降价的商品，这些商品的价格是否又回升了对全网比价的质量影响很大，所以，全网比价的商品列表也须要常常被更新，以防止过期的降价信息影响用户体验度。

总结一下，数据来源的使用主要有三点。第1、尽量地利用多种数据来源，使价格可以被更快速及时地更新；第2、首先保证热门商品的价格被及时更新，热门商品的列表来自于用户的浏览记录与搜索历史等；第3、不能忽略非热门的商品，非热门商品虽然被用户访问的次数少，但也须要按期地被更新，只是更新间隔略长一些。

4、总结

本文主要以购物搜索价格服务器，辅以 Google 咖啡因，Linkedin 的 Databus 为例，介绍了大数据实时更新框架的设计思想。框架的共同点是：

一、观察者模式

二、细粒度的更新数据到应用层。对比过去 MapReduce 的批量更新机制，更好的解决了大数据和实时性这两大痛点。

Refer：

[1] 大数据实时更新框架

http://techblog.youdao.com/?p=459

http://dwz.cn/2ho6cW

[2] 《JAVA与模式》之观察者模式

http://www.cnblogs.com/java-my-life/archive/2012/05/16/2502279.html

[3] JAVA设计模式学习19——观察者模式

http://alaric.iteye.com/blog/1924169