Viacom：Redis在系統(tǒng)中的用例盤點
Viacom是全球最大的傳媒集體之一，同時也遭遇了當下最大的數據難題之一：如何處理日益劇增的動態(tài)視頻內容。
著眼這一挑戰(zhàn)的上升趨勢，我們會發(fā)現：2010年世界上所有數據體積達到ZB級，而單單2012這一年，互聯(lián)網產生的數據就增加了2.8個ZB，其中大部分的數據都是非結構化的，包括了視頻和圖片。
覆蓋MVN（以前稱為MTV Networks、Paramount及BET），Viacom是個名副其實的傳媒巨頭，支持眾多人氣站點， 其中包括The Daily Show、osh.0、South Park Studios、GameTrailers.com等。作為媒體公司，這些網 站上的文檔、圖片、視頻短片都在無時無刻的更新。長話短說，下面就進入Viacom高級架構師Michael Venezia 分享的Redis實踐：
Viacom的網站架構背景
對于Viacom，橫跨多個站點傳播內容讓必須專注于規(guī)模的需求，同時為了將內容竟可能快的傳播到相應用戶，他們還必須聚焦內容之間的關 系。然而即使The Daily Show、Nickelodeon、Spike或者是VH1 這些單獨的網站上，日平均PV都可以達到千萬，峰值時流量 更會達到平均值的20-30倍。同時基于對實時的需求，動態(tài)的規(guī)模及速度已成為架構的基礎之一。
除去動態(tài)規(guī)模之外，服務還必須基于用戶正在瀏覽的視頻或者是地理位置來推測用戶的喜好。比如說，某個頁面可能會將一個獨立的視頻片段與本地 的促銷，視頻系列的額外部分，甚至是相關視頻聯(lián)系起來。為了能讓用戶能在網站上停留更長的時間，他們建立了一個能基于詳細元數據自動建立頁面的軟件引擎， 這個引擎可以根據用戶當下興趣推薦額外的內容。鑒于用于興趣的隨時改變，數據的類型非常廣泛——類似graph-like，實際上做的是大量的join。
這樣做有利于減少類似視頻的大體積文件副本數，比如數據存儲中一個獨立的記錄是Southpark片段 “Cartman gets an Anal Probe”，這個片段可能也會出現在德語的網站上。雖然視頻是一樣的，但是英語用戶搜索的可能就是另一個 不同的詞語。元數據的副本轉換成搜索結果，并指向相同的視頻。因此在美國用戶搜索真實標題的情況下，德國瀏覽者可能會使用轉譯的標題——德國網站上的 “Cartman und die Analsonde”。
這些元數據覆蓋了其它記錄或者是對象，同時還可以根據使用環(huán)境來改變內容，通過不同的規(guī)則集來限制不同地理位置或者是設備請求的內容。
Viacom的實現方法
盡管許多機構通過使用ORM及傳統(tǒng)關系型數據庫來解決這個問題，Viacom卻使用了一個迥然不同的方法。
本質上，他們完全承擔不了對數據庫的直接訪問。首先，他們處理的大部分都是流數據，他們偏向于使用Akamai從地理上來分配內容。其次， 基于頁面的復雜性可能會取上萬個對象。取如此多的數據顯然會影響到性能，因此JSON在1個數據服務中投入了使用。當然，這些JSON對象的緩存將直接影 響到網站性能。同時，當內容或者是內容之間的關系發(fā)生改變時，緩存還需要動態(tài)的進行更新。
Viacom依靠對象基元和超類解決這個問題，繼續(xù)以South Park為例：一個私有的“episode”類包含了所有該片段相關信 息，一個“super object”將有助于發(fā)現實際的視頻對象。超類這個思想確實非常有益于建設低延遲頁面的自動建設，這些超類可以幫助到基元對象到 緩存的映射及保存。