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

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

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

• 乘客信息、司機信息

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

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

• 訂單、可用車輛、定價

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

 

 

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

 

 

而日志作為非結構化的數據，不適用于關系型數據庫，這類數據包括：

• 微服務架構

• 數據分析

• 需求跟蹤，調試

• 實時數據

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

 

 

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

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

 

 

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

 

 

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

 

 

消費者對于數據的要求無非以下六個維度：

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

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

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

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

 

 

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

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

 

 

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

 

 

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

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

 

標簽： Mysql 安全 數據分析 數據庫

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