3月19日消息，今晚刷微博，突然發現有朋友再說淘寶旺旺服務器可能癱瘓了，因為賣家集體高冷，什麼問題都不回答了。直接上圖

來說說旺旺服務器吧，大家可能不大清楚，畢竟在我們看來雙十一這樣的電商節淘寶都沒事現在就出事了?

淘寶海量數據産品技術架構

數據産品的一個最大特點是數據的非實時寫入，正因為如此，我們可以認為，在一定的時間段内，整個系統的數據是隻讀的。這為我們設計緩存奠定了非常重要的基礎。

圖1 淘寶海量數據産品技術架構

按照數據的流向來劃分，我們把淘寶數據産品的技術架構分為五層(如圖1所示)，分别是數據源、計算層、存儲層、查詢層和産品層。位于架構頂端的是我們的數據來源層，這裡有淘寶主站的用戶、店鋪、商品和交易等數據庫，還有用戶的浏覽、搜索等行為日志等。這一系列的數據是數據産品最原始的生命力所在。

在數據源層實時産生的數據，通過淘寶自主研發的數據傳輸組件DataX、DbSync和Timetunnel準實時地傳輸到一個有1500個節點的Hadoop集群上，這個集群我們稱之為“雲梯”，是計算層的主要組成部分。在“雲梯”上，我們每天有大約40000個作業對1.5PB的原始數據按照産品需求進行不同的MapReduce計算。這一計算過程通常都能在淩晨兩點之前完成。相對于前端産品看到的數據，這裡的計算結果很可能是一個處于中間狀态的結果，這往往是在數據冗餘與前端計算之間做了适當平衡的結果。

不得不提的是，一些對實效性要求很高的數據，例如針對搜索詞的統計數據，我們希望能盡快推送到數據産品前端。這種需求再采用“雲梯”來計算效率将是比較低的，為此我們做了流式數據的實時計算平台，稱之為“銀河”。“銀河”也是一個分布式系統，它接收來自TimeTunnel的實時消息，在内存中做實時計算，并把計算結果在盡可能短的時間内刷新到NoSQL存儲設備中，供前端産品調用。

容易理解，“雲梯”或者“銀河”并不适合直接向産品提供實時的數據查詢服務。這是因為，對于“雲梯”來說，它的定位隻是做離線計算的，無法支持較高的性能和并發需求;而對于“銀河”而言，盡管所有的代碼都掌握在我們手中，但要完整地将數據接收、實時計算、存儲和查詢等功能集成在一個分布式系統中，避免不了分層，最終仍然落到了目前的架構上。

為此，我們針對前端産品設計了專門的存儲層。在這一層，我們有基于MySQL的分布式關系型數據庫集群MyFOX和基于HBase的NoSQL存儲集群Prom，在後面的文字中，我将重點介紹這兩個集群的實現原理。除此之外，其他第三方的模塊也被我們納入存儲層的範疇。

存儲層異構模塊的增多，對前端産品的使用帶來了挑戰。為此，我們設計了通用的數據中間層——glider——來屏蔽這個影響。glider以HTTP協議對外提供restful方式的接口。數據産品可以通過一個唯一的URL獲取到它想要的數據。以上是淘寶海量數據産品在技術架構方面的一個概括性的介紹。

淘寶數據産品選擇MySQL的MyISAM引擎作為底層的數據存儲引擎。在此基礎上，為了應對海量數據，我們設計了分布式MySQL集群的查詢代理層——MyFOX，使得分區對前端應用透明。

圖 MyFOX的數據查詢過程

目前，存儲在MyFOX中的統計結果數據已經達到10TB，占據着數據魔方總數據量的95%以上，并且正在以每天超過6億的增量增長着。這些數據被我們近似均勻地分布到20個MySQL節點上，在查詢時，經由MyFOX透明地對外服務。

圖 MyFOX節點結構

值得一提的是，在MyFOX現有的20個節點中，并不是所有節點都是“平等”的。一般而言，數據産品的用戶更多地隻關心“最近幾天”的數據，越早的數據，越容易被冷落。為此，出于硬件成本考慮，我們在這20個節點中分出了“熱節點”和“冷節點”(如圖4所示)。

顧名思義，“熱節點”存放最新的、被訪問頻率較高的數據。對于這部分數據，我們希望能給用戶提供盡可能快的查詢速度，所以在硬盤方面，我們選擇了每分鐘15000轉的SAS硬盤，按照一個節點兩台機器來計算，單位數據的存儲成本約為4.5W/TB。相對應地，“冷數據”我們選擇了每分鐘7500轉的SATA硬盤，單碟上能夠存放更多的數據，存儲成本約為1.6W/TB。

将冷熱數據進行分離的另外一個好處是可以有效提高内存磁盤比。從圖4可以看出，“熱節點”上單機隻有24GB内存，而磁盤裝滿大約有1.8TB(300 * 12 * 0.5 / 1024)，内存磁盤比約為4:300，遠遠低于MySQL服務器的一個合理值。内存磁盤比過低導緻的後果是，總有一天，即使所有内存用完也存不下數據的索引了——這個時候，大量的查詢請求都需要從磁盤中讀取索引，效率大打折扣。

隻能說，淘寶服務器出問題可能是數據庫問題也可能是解析。具體問題等阿裡出公告吧。

小芳 村裡的那個姑娘

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!