● 在滴滴練習(xí)

● 我們使用更多的開源數(shù)據(jù)庫(kù)

● 嘗試整合數(shù)據(jù)庫(kù)

● 考慮集成數(shù)據(jù)庫(kù)實(shí)踐的入口

文章摘要：

經(jīng)過多年發(fā)展，已成為開源數(shù)據(jù)庫(kù)中最重要的產(chǎn)品，擁有成熟的應(yīng)用場(chǎng)景和生態(tài)工具。在實(shí)踐的過程中，使用不同的存儲(chǔ)技術(shù)來(lái)處理不同領(lǐng)域的問題也是共識(shí)，因此諸如 、 、 等產(chǎn)品也被應(yīng)用到了不同的生產(chǎn)線上。過去，工程師需要將數(shù)據(jù)寫入各種存儲(chǔ)系統(tǒng)，不僅增加了技術(shù)實(shí)現(xiàn)的難度，也增加了相應(yīng)的成本?，F(xiàn)在，通過圍繞結(jié)構(gòu)化數(shù)據(jù)做ETL，只需要更新數(shù)據(jù)并將數(shù)據(jù)分發(fā)到不同的存儲(chǔ)服務(wù)。單元化、同城雙活等場(chǎng)景變得更加自然和簡(jiǎn)單。本次分享將數(shù)據(jù)庫(kù)與周邊生態(tài)工具整合的實(shí)踐。通過開源協(xié)作，圍繞中心的融合數(shù)據(jù)庫(kù)技術(shù)將大大降低企業(yè)使用開源數(shù)據(jù)庫(kù)的成本。

文字語(yǔ)音：

大家好，我叫沉金迪，來(lái)自滴滴出行網(wǎng)站開發(fā)，主要服務(wù)于基礎(chǔ)設(shè)施團(tuán)隊(duì)和滴滴云產(chǎn)品技術(shù)團(tuán)隊(duì)。今天給大家分享滴滴在數(shù)據(jù)庫(kù)層面的實(shí)踐。如今，滴滴的整體規(guī)模和體量都比較大。如何以低成本快速提高效率，實(shí)現(xiàn)業(yè)務(wù)目標(biāo)，成為了技術(shù)團(tuán)隊(duì)的核心價(jià)值。

“融合數(shù)據(jù)庫(kù)”是我今天要分享的話題。一開始我覺得這個(gè)話題可能有點(diǎn)太大了，但我又想，我想和大家分享這個(gè)觀點(diǎn)。因?yàn)榈蔚螐囊患冶容^小規(guī)模的互聯(lián)網(wǎng)公司成長(zhǎng)為一家快速成長(zhǎng)的互聯(lián)網(wǎng)公司，也向很多騰云網(wǎng)絡(luò)學(xué)習(xí)，學(xué)到了很多技術(shù)經(jīng)驗(yàn)和知識(shí)。

一.在滴滴實(shí)習(xí)

滴滴現(xiàn)已在所有核心業(yè)務(wù)場(chǎng)景中使用。訂單、付款、余額等都放在里面，非常安全。為什么安全？因?yàn)槲覀冇袑ｉT的運(yùn)維和研發(fā)團(tuán)隊(duì)，所以我們花了一年時(shí)間將5.5、5.6版本全面升級(jí)到5.7。雖然我們也在關(guān)注 5.8，但 5.7 將作為基準(zhǔn)版本存在很長(zhǎng)時(shí)間。

我們?cè)谶@方面做了一些非常有趣的實(shí)踐?，F(xiàn)在云服務(wù)已經(jīng)很成熟了php訂單管理系統(tǒng) 開源，大家都習(xí)慣用RDS了，所以我們的工程師第一天就問有沒有RDS的產(chǎn)品可以用。老實(shí)說，一開始并沒有這樣的事情。 2015年，我們開始組建RDS團(tuán)隊(duì)，希望將云服務(wù)和基礎(chǔ)設(shè)施即服務(wù)的理念帶到滴滴的整個(gè)基礎(chǔ)設(shè)施建設(shè)中。因此，它是我們制作的第一個(gè)基礎(chǔ)設(shè)施服務(wù)產(chǎn)品。

我們的數(shù)據(jù)庫(kù)研發(fā)+中間件+自動(dòng)化運(yùn)維團(tuán)隊(duì)大概3到4人，當(dāng)然也會(huì)有DBA支持，基本實(shí)現(xiàn)了所有工程師的自助服務(wù)，大約95%的工單自動(dòng)完成，經(jīng)主管批準(zhǔn)并經(jīng)DBA確認(rèn)后自動(dòng)執(zhí)行。

我們?cè)趪?guó)內(nèi)外的所有流程都是一致的，幾乎都是基于，例如備份、監(jiān)控、配套設(shè)施都進(jìn)行了改造，除了數(shù)據(jù)庫(kù)部分或者物理機(jī)的混合部署。滴滴的目標(biāo)是在一兩年內(nèi)實(shí)現(xiàn)全平臺(tái)容器化。當(dāng)然，這個(gè)目標(biāo)的實(shí)現(xiàn)也是具有挑戰(zhàn)性的，因?yàn)榈蔚斡写罅康拇a模塊，尤其是在數(shù)據(jù)庫(kù)層面，要實(shí)現(xiàn)容器化還有很多問題需要解決。

一年前，我們團(tuán)隊(duì)解決了IO隔離、穩(wěn)定性等一系列問題，接下來(lái)我們將著手整個(gè)數(shù)據(jù)庫(kù)的遷移工作。

目前，滴滴的日均訂單量為3000萬(wàn)，在中國(guó)的訂單量相對(duì)較高。峰值訂單為每秒 60,000 個(gè)。這個(gè)數(shù)值可能無(wú)法與阿里相提并論，但我們的復(fù)雜性也不在于訂單數(shù)量，而在于如何在龐大的乘客需求和司機(jī)容量之間找到最合理的訂單。

以下是滴滴實(shí)踐中的一些情況。

整個(gè)用戶控制臺(tái)包括DDL權(quán)限管理、SQL異常統(tǒng)計(jì)、審計(jì)、黑名單等。相信做過DBA運(yùn)維工作的朋友都覺得申請(qǐng)數(shù)據(jù)庫(kù)白名單的繁瑣，而我們通過API和白名單將所有的服務(wù)和組織結(jié)構(gòu)序列化，工程師只要發(fā)布應(yīng)用自然就可以訪問自己的數(shù)據(jù)庫(kù).

我們有一個(gè)前端和兩個(gè)工程師做自動(dòng)化運(yùn)維控制臺(tái)，所以DBA有更多的精力專注于數(shù)據(jù)驗(yàn)證和機(jī)房搬遷。

上圖是一個(gè)簡(jiǎn)單的數(shù)據(jù)結(jié)構(gòu)，分為三個(gè)場(chǎng)景：在線業(yè)務(wù)系統(tǒng)、在線輔助系統(tǒng)和自動(dòng)化運(yùn)維系統(tǒng)。滴滴從一開始就考慮了分庫(kù)分表，這是由順序決定的。在單臺(tái)機(jī)器上存儲(chǔ)如此大量的數(shù)據(jù)更具挑戰(zhàn)性。

所以從一開始，我們就有兩名工程師專門負(fù)責(zé)維護(hù)開發(fā)工作。數(shù)據(jù)庫(kù)是標(biāo)準(zhǔn)的一主雙從結(jié)構(gòu)，MHA切換，在分庫(kù)分表的情況下我們也做了一些有趣的能力實(shí)現(xiàn)二級(jí)索引；類似的備份、審計(jì)系統(tǒng)、慢日志等由輔助業(yè)務(wù)系統(tǒng)實(shí)現(xiàn)；并將自動(dòng)化運(yùn)維系統(tǒng)開發(fā)設(shè)計(jì)為云產(chǎn)品。

做一個(gè)好的中間件是現(xiàn)在數(shù)據(jù)庫(kù)的核心。如果沒有中間件，未來(lái)很難進(jìn)行自動(dòng)化運(yùn)維、擴(kuò)容，甚至業(yè)務(wù)功能。比如主從有延遲，讀寫分離是很自然的場(chǎng)景，但是有些業(yè)務(wù)不能容忍延遲。如果讀備庫(kù)，會(huì)出現(xiàn)一致性問題，所以在中間件層面，我們會(huì)在SQL前加注強(qiáng)制讀取主庫(kù)，解決一致性問題，然后再讀取從庫(kù)進(jìn)行其他企業(yè)。而如果沒有支持，審計(jì)自動(dòng)化運(yùn)維將會(huì)帶來(lái)巨大的挑戰(zhàn)。

此外，滴滴還有幾個(gè)關(guān)鍵能力，比如內(nèi)置二級(jí)索引、單元化等，單元化在滴滴的應(yīng)用比較明顯?，F(xiàn)在滴滴既有國(guó)內(nèi)業(yè)務(wù)，也有國(guó)外業(yè)務(wù)，這兩個(gè)業(yè)務(wù)的數(shù)據(jù)是完全隔離的。我們用一套代碼和一套技術(shù)來(lái)實(shí)現(xiàn)國(guó)內(nèi)業(yè)務(wù)。與國(guó)外平行。下一步，我們將在中國(guó)實(shí)行單元化，整個(gè)業(yè)務(wù)南北拆分。北方用戶的訂單數(shù)據(jù)放在北方機(jī)房，南方用戶的數(shù)據(jù)放在南方機(jī)房。

二.我們使用更多的開源數(shù)據(jù)庫(kù)

滴滴的每個(gè)產(chǎn)品都有一個(gè)用戶控制臺(tái)，所有的基礎(chǔ)設(shè)施服務(wù)都得到了徹底的實(shí)現(xiàn)，從數(shù)據(jù)庫(kù)服務(wù)發(fā)現(xiàn)到緩存消息隊(duì)列再到長(zhǎng)鏈接，只要你想得到所有的自助服務(wù)。我們希望整個(gè)運(yùn)維效率能夠大大提高，人工干預(yù)和決策減少。

我們?nèi)匀皇褂眉鹤鳛殡x線場(chǎng)景和MIS場(chǎng)景，但正在朝著主存儲(chǔ)的方向發(fā)展。目前，主營(yíng)業(yè)務(wù)也在使用。這是因?yàn)樗亩嗑S索引非常有用，工程師可以使用它。也比較容易，規(guī)模大概在幾千左右。

主流的開源數(shù)據(jù)庫(kù)都在使用中，如，、、、、、。除了標(biāo)準(zhǔn)的關(guān)系型數(shù)據(jù)庫(kù)，還有兩個(gè)不同場(chǎng)景的自研系統(tǒng)。一種是我們用來(lái)存儲(chǔ)功能引擎，例如訂單、驅(qū)動(dòng)程序等。

DiDi 在早期被大量使用。工程師通常將其用作存儲(chǔ)服務(wù)而不是緩存服務(wù)，但這給滴滴帶來(lái)了很多麻煩。在數(shù)據(jù)量特別大的情況下，一臺(tái)機(jī)器只能存儲(chǔ)幾百G。于是，又引入了另一個(gè)系統(tǒng)——基于。系統(tǒng)實(shí)現(xiàn)了跨機(jī)房的單元化和一致性，我們的核心數(shù)據(jù)也在嘗試使用自研引擎提供服務(wù)。

滴滴現(xiàn)在都是開源的，從數(shù)據(jù)庫(kù)層面到編程語(yǔ)言再到框架等等都是開源實(shí)現(xiàn)的。我們熱愛開源，會(huì)回饋開源，未來(lái)系統(tǒng)也會(huì)開源。

三.整合數(shù)據(jù)庫(kù)的嘗試

為什么分庫(kù)分表的情況下需要做二級(jí)索引？比如集群中有key，使用 ID創(chuàng)建分庫(kù)分表。如果要查詢乘客或司機(jī)的訂單怎么辦？工程師認(rèn)為再建一個(gè)索引就夠了，但是分庫(kù)表就很難了。 所以工程師花了很多精力寫了兩張表，先寫訂單數(shù)據(jù)庫(kù)，再寫司機(jī)索引，再寫乘客索引。這還不夠，MIS還需要用到一、的兩個(gè)維度。工程師寫的大部分代碼都是為了保證所有索引都寫成功，但是有時(shí)候發(fā)布的時(shí)候數(shù)據(jù)會(huì)丟失。這個(gè)問題困擾我們很久了。

這個(gè)問題當(dāng)然可以通過分布式事務(wù)產(chǎn)品在技術(shù)上解決，但是使用起來(lái)有點(diǎn)麻煩，所以我們從另一個(gè)維度進(jìn)行了嘗試。假設(shè)還有訂單ID和乘客ID兩個(gè)維度，我們實(shí)現(xiàn)了一個(gè)克隆系統(tǒng)php訂單管理系統(tǒng) 開源，從主庫(kù)更新完所有數(shù)據(jù)后，復(fù)制到另一個(gè)表。邏輯自動(dòng)完成，相當(dāng)于創(chuàng)建表時(shí)創(chuàng)建索引，分庫(kù)分表的情況下創(chuàng)建主鍵，索引鍵的情況下自動(dòng)將數(shù)據(jù)復(fù)制到另一張表中查詢中自動(dòng)識(shí)別，直接查詢。

這對(duì)工程師來(lái)說是一種極大的解放。一個(gè)表中的兩個(gè)索引也可以工作。當(dāng)然，這也有局限性，但至少解決了寫兩張表的問題。這是我們基于 的第一次嘗試，解決了很多業(yè)務(wù)問題，大大降低了整體代碼復(fù)雜度。

第二次嘗試是與 ES 的集成。上圖是典型的架構(gòu)圖，業(yè)務(wù)代碼是from to。其中，我們使用了阿里巴巴開源的中間件。我們將數(shù)據(jù)同步并寫入 ES。

這樣做的好處是在ES中建表，可以做到分鐘級(jí)甚至秒級(jí)的數(shù)據(jù)查詢，體驗(yàn)非常好。但是也會(huì)有問題。我們的代碼大部分是 PHP 和 Go，所以工程師會(huì)覺得提供一個(gè)協(xié)議 ES 查詢引擎很麻煩。

正因?yàn)槿绱?，YASE引擎誕生了，它支持通過去訪問ES。我們?cè)Ｍ磺卸际情T戶，但結(jié)果證明這不是一個(gè)好的解決方案。因?yàn)镋S API的原生客戶端和訪問協(xié)議各有優(yōu)勢(shì)，靈活性和定制性更強(qiáng)。如果降級(jí)為標(biāo)準(zhǔn)的SQL協(xié)議，會(huì)損失很多能力，得不償失。

四.我想入口的融合數(shù)據(jù)庫(kù)

于是我們開始嘗試整合數(shù)據(jù)庫(kù)，最典型的就是業(yè)務(wù)代碼會(huì)同時(shí)寫，或者ES。大多數(shù)公司依次將數(shù)據(jù)寫入每個(gè)數(shù)據(jù)庫(kù)。寫完，產(chǎn)品還是很多的。比如我們雖然只有兩個(gè)從庫(kù)，但是應(yīng)用還是很多的，比如，YAES等。

寫入各種克隆系統(tǒng)和異構(gòu)存儲(chǔ)系統(tǒng)也給運(yùn)維帶來(lái)很多麻煩。 DBA 認(rèn)為光是運(yùn)維就夠復(fù)雜了。同步多個(gè)副本。

于是我們想出了一個(gè)新思路，在層級(jí)屏蔽一切，只提供一個(gè)服務(wù)，全部消費(fèi)給 DDMQ。 DDMQ是基于阿里巴巴實(shí)現(xiàn)的帶有事務(wù)的MQ引擎，至少可以消費(fèi)一次消息隊(duì)列。預(yù)計(jì)2018年完成DDMQ的完全開源。

我們把一切都和DDMQ集成在一起，也就是說，我們可以直接向DDMQ發(fā)送消息，這實(shí)際上是一個(gè)升級(jí)版。因?yàn)橛蠨DMQ的存在，我們整個(gè)延遲，包括事務(wù)性，都有很大的保障。

同時(shí)，在此基礎(chǔ)上，我們實(shí)現(xiàn)了DDMQ的ETL工作。滴滴目前的ETL工作還比較原始，但是我們的一些業(yè)務(wù)線已經(jīng)開始嘗試使用規(guī)則引擎來(lái)實(shí)現(xiàn)ETL工作。如果驗(yàn)證通過，會(huì)快速切換到頂部，并通過DDMQ將數(shù)據(jù)同步到ES，應(yīng)用程序不需要實(shí)現(xiàn)寫入。有多個(gè)副本。看來(lái)業(yè)務(wù)工程師只寫一張表就可以訪問多個(gè)數(shù)據(jù)源，整個(gè)訪問方式并沒有改變。

接下來(lái)介紹融合數(shù)據(jù)庫(kù)的場(chǎng)景。

第一個(gè)是克隆系統(tǒng)。二級(jí)索引值只寫一次，但是可以支持很多索引，但是也需要限制，因?yàn)槿绻饕?a href='http://dl-ea.com/'>seo優(yōu)化，會(huì)影響整個(gè)延遲。索引不是問題。

第二個(gè)是緩存反沖。我們的很多代碼都是 PHP 代碼。它有一個(gè)特點(diǎn)，可以隨時(shí)殺死。一旦被殺掉，緩存可能會(huì)更新失效，業(yè)務(wù)代碼對(duì)緩存的依賴很重。如果沒有事務(wù)緩存更新，工程師會(huì)寫越來(lái)越多的代碼。

第三個(gè)是單元化，跨機(jī)房和大洲同步數(shù)據(jù)。 2017年，滴滴開始國(guó)際化，2018年正式啟動(dòng)南美和北美國(guó)際業(yè)務(wù)。我們使用這項(xiàng)技術(shù)進(jìn)行數(shù)據(jù)同步。從南美到北美的數(shù)據(jù)遷移是自動(dòng)化的。北美數(shù)據(jù)室跑起來(lái)，自動(dòng)完成數(shù)據(jù)復(fù)制，邊寫邊復(fù)制。時(shí)間一到，就按城市切分。

第四個(gè)支持ES索引，MIS數(shù)據(jù)更新延遲到第二級(jí)；

第五次實(shí)時(shí)數(shù)據(jù)同步，所有表實(shí)時(shí)復(fù)制到HDFS。去年，我們的方法是在 12:00 開始拉數(shù)據(jù)庫(kù)。拉完之后，整個(gè)數(shù)據(jù)中心都很熱鬧。但是現(xiàn)在數(shù)據(jù)最快可以統(tǒng)計(jì)到12:00。整個(gè)數(shù)據(jù)計(jì)算時(shí)間大大減少，但是為了保證數(shù)據(jù)的可靠性，我們?cè)跀?shù)據(jù)的校驗(yàn)和可靠性上花費(fèi)了很多精力。

以實(shí)時(shí)業(yè)務(wù)監(jiān)控為例，滴滴每天可能有 20 到 3000 萬(wàn)個(gè)訂單，你怎么知道一個(gè)城市的交易量是同比下降還是上升？我們?cè)贒TS平臺(tái)上連接了實(shí)時(shí)監(jiān)控和實(shí)時(shí)消費(fèi)，實(shí)時(shí)分析，非常低的延遲，幾秒就能知道交易是否掉線了。

我們有一個(gè) as 的概念，它涵蓋了 OLTP 和 OLAP 場(chǎng)景。我們的目標(biāo)是為入口寫一條數(shù)據(jù)，有多種訪問形式。

上圖是我們對(duì)DTS的理解，形成了一種融合的存儲(chǔ)服務(wù)。 DTS也在不斷演進(jìn)中，下一個(gè)目標(biāo)我們希望用規(guī)則和腳本來(lái)實(shí)現(xiàn)ETL。在OLAP大數(shù)據(jù)場(chǎng)景中，我們使用過。在實(shí)時(shí)鏈路層，我們也分享了如何做實(shí)時(shí)大數(shù)據(jù)同步。除了數(shù)據(jù)庫(kù)問題，我們還解決了一些日志問題……我們熱愛開源，擁抱開源，也樂于分享。