三月份在美國參加MVP峰會的時候，有幸碰到了幾個Uber的高級工程師，他們在當(dāng)天還分享了Uber的消息總線系統(tǒng)如何在每日兆級信息量、PB級數(shù)據(jù)卷、數(shù)萬個Topic的情況下，保證低延時(小于5ms)，高可用(99.99%),高穩(wěn)定(99.99%，核心客戶100%)的。

有朋友對Uber這種打車軟件公司能達到這樣的數(shù)據(jù)量感到不以為然，認為只有社交類(如Facebook、領(lǐng)英，微信)和在線零售(如Ebay、亞馬遜，淘寶)的公司才有這樣的體量。其實上述的數(shù)據(jù)量只是Uber的單個數(shù)據(jù)副本，作為一家遍布全球超過400個城市的出行公司，Uber需要存儲世界各地的地圖數(shù)據(jù);其次，它還需要對這些城市的交通狀況做出精確分析，以便對任意時間的路面進行預(yù)測;最后，Uber內(nèi)部還有分析師和數(shù)據(jù)科學(xué)家需要調(diào)閱每周的財務(wù)收支情況及用戶反饋，以及時調(diào)整運營策略或調(diào)整路線算法。

總體來說，Uber的數(shù)據(jù)生產(chǎn)者分為兩類，一是核心業(yè)務(wù)數(shù)據(jù)，包括：

• 乘客信息、司機信息

• 路程規(guī)劃、賬單

• 司機狀態(tài)變更

• 訂單、可用車輛、定價

以上數(shù)據(jù)對可用性、實時性要求非常高，因此存儲在在線數(shù)據(jù)庫(OLTP)中。

 

 

第二類數(shù)據(jù)是日志和事件數(shù)據(jù)。就在幾年前，Uber從傳統(tǒng)SOA框架轉(zhuǎn)為微服務(wù)，它使運維和開發(fā)變得更靈活，并支持非關(guān)系型數(shù)據(jù)庫。

 

 

而日志作為非結(jié)構(gòu)化的數(shù)據(jù)，不適用于關(guān)系型數(shù)據(jù)庫，這類數(shù)據(jù)包括：

• 微服務(wù)架構(gòu)

• 數(shù)據(jù)分析

• 需求跟蹤，調(diào)試

• 實時數(shù)據(jù)

這部分數(shù)據(jù)使用流式的Kafka消息總線作為其核心傳輸模塊。

 

 

上圖中左邊是消息生產(chǎn)者，包括乘客端App，司機端App，以及第三方應(yīng)用通過調(diào)用Uber的API采集來的消息。消息的生產(chǎn)者還包括一部分數(shù)據(jù)庫，來存放用戶操作記錄等信息：其中MySQL用于存放結(jié)構(gòu)化數(shù)據(jù);Schemaless主要存放非結(jié)構(gòu)化數(shù)據(jù);Cassandra用來存放需要在各數(shù)據(jù)中心之間同步的核心數(shù)據(jù)(因為其低延遲的復(fù)制效率)。通過Kafka的處理，再由不同的消費者各取所需，例如Surge拉取數(shù)據(jù)計算車費;ELK拉取實時日志數(shù)據(jù)生成運行狀態(tài)儀表盤;AWS S3和Hadoop拉取數(shù)據(jù)做一些實時性要求不那么高的離線數(shù)據(jù)處理。

為保證總線的高可用，每個站點還部署有備用Kafka，以便在主Kafka集群宕機時，將生產(chǎn)者的數(shù)據(jù)緩存下來，等主集群恢復(fù)了再切換回去。不同數(shù)據(jù)中心的Kafka通過uReplicator(Kafka的鏡像生成器)進行匯總后輸出。

 

 

當(dāng)然全局的和本地的數(shù)據(jù)都有消費市場，比如全局有補丁管理，本地化有計價系統(tǒng)，他們在上圖不同的Kafka之后(Regional或Aggregate)被依次消費掉。

 

 

不光如此，不同的消費者對于數(shù)據(jù)是有不同的需求維度的。近些年來新的數(shù)據(jù)庫層出不窮，尤其是NoSQL數(shù)據(jù)庫趕上了好時代而層出不窮，小編常被問及哪個數(shù)據(jù)庫最強大，其實這并沒有定論，關(guān)鍵要看需求的維度。

 

 

消費者對于數(shù)據(jù)的要求無非以下六個維度：

• 響應(yīng)速度：如果數(shù)據(jù)庫性能足夠強大，沒有附加串聯(lián)系統(tǒng)，數(shù)據(jù)都在內(nèi)存中交互，那響應(yīng)速度無疑是可以保證的

• 查詢便捷性：要開放更多的查詢維度(或者說更多的查詢條件)，勢必要定義更多的Key，因此會犧牲數(shù)據(jù)庫性能，最明顯的是響應(yīng)延時;

• 安全性：Uber的數(shù)據(jù)調(diào)取需要經(jīng)過反欺詐等系統(tǒng)的過濾，因此加強數(shù)據(jù)安全也會帶來延時;

• 數(shù)據(jù)可靠性：有些高訪問量的應(yīng)用為了提高用戶體驗，會在(交易)數(shù)據(jù)入庫前就將后續(xù)指令返回給用戶了。

 

 

比如用戶在某購物APP上買一雙鞋，交易在進入數(shù)據(jù)庫之前可能就會向用戶征收費用，這一方面是為了用戶體驗，另一方面大部分數(shù)據(jù)庫同一時間只有一個讀寫副本，有時數(shù)據(jù)寫入磁盤確實是個漫長的等待過程，所以APP將交易提交給后端緩存就認為交易已經(jīng)入庫，可以開始收費，但如果這時數(shù)據(jù)庫宕機了，緩存數(shù)據(jù)丟失了，那就等于收了客戶的錢沒有給客戶發(fā)貨，因為數(shù)據(jù)庫里沒有這筆訂單。當(dāng)然訂單入庫再返回響應(yīng)勢必會慢很多，因為磁盤讀寫速度是遠不及內(nèi)存的，這一點又是與用戶體驗之間的博弈。

很多數(shù)據(jù)庫默認都是異步寫入，比如MongoDB，它甚至寫入成功后也不會返回給應(yīng)用任何確認入庫的信息;再比如Redis，它完全就是一個不可靠的數(shù)據(jù)庫，他會給數(shù)據(jù)做快照，但快照不會存入磁盤，因此Redis只能用于數(shù)據(jù)緩存層。

 

 

• 數(shù)據(jù)一致性：逛論壇的朋友經(jīng)常會碰到這樣的事情，就是一個主題或者一個回復(fù)我明明只發(fā)了一次，刷新頁面卻蹦出來一堆，這就是數(shù)據(jù)庫的一致性檢查沒做好。一般的控制方法是限制單位時間的更新頻率，或者優(yōu)化業(yè)務(wù)邏輯，當(dāng)然這也要犧牲一部分數(shù)據(jù)庫性能。

 

 

• 系統(tǒng)可用性：可用性，一般是指當(dāng)某個數(shù)據(jù)中心發(fā)生災(zāi)難時，應(yīng)用是否依然可用，數(shù)據(jù)是否依然可以訪問。

在顯然無法兼顧所有維度的前提下，作為一款打車軟件，在保證響應(yīng)速度、安全性、查詢便捷性和系統(tǒng)高可用的情況下，適度地放棄數(shù)據(jù)一致性和可靠性是可以接收的。另外，可延展性(Scalability)是Kafka及其消費端軟件本身就具有的特點。

 

標(biāo)簽： Mysql 安全 數(shù)據(jù)分析 數(shù)據(jù)庫

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。