網易惠惠購物助手：大數據實時更新框架概述

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