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

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

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

• 乘客信息、司機(jī)信息

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

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

• 訂單、可用車輛、定價(jià)

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

 

 

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

 

 

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

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

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

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

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

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

 

 

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

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

 

 

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

 

 

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

 

 

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

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

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

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

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

 

 

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

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

 

 

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

 

 

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

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

 

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

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