摘要：而隨著分布式數(shù)據(jù)庫大放異彩，美團團隊聯(lián)合基礎(chǔ)架構(gòu)存儲團隊，于年初啟動了分布式數(shù)據(jù)庫項目?？鐧C房雙寫支持跨機房雙寫是數(shù)據(jù)庫領(lǐng)域一大難題，是我們對分布式數(shù)據(jù)庫的一個重要期待，也是美團下一階段重要的需求。

近幾年，基于MySQL構(gòu)建的傳統(tǒng)關(guān)系型數(shù)據(jù)庫服務(wù)，已經(jīng)很難支撐美團業(yè)務(wù)的爆發(fā)式增長，這就促使我們?nèi)ヌ剿鞲侠淼臄?shù)據(jù)存儲方案和實踐新的運維方式。而隨著分布式數(shù)據(jù)庫大放異彩，美團DBA團隊聯(lián)合基礎(chǔ)架構(gòu)存儲團隊，于 2018 年初啟動了分布式數(shù)據(jù)庫項目。

圖 1 美團點評產(chǎn)品展示圖

在立項之初，我們進行了大量解決方案的對比，深入了解了業(yè)界的 scale-out（橫向擴展）、scale-up（縱向擴展）等解決方案。但考慮到技術(shù)架構(gòu)的前瞻性、發(fā)展?jié)摿Α⑸鐓^(qū)活躍度以及服務(wù)本身與 MySQL 的兼容性，我們最終敲定了基于 TiDB 數(shù)據(jù)庫進行二次開發(fā)的整體方案，并與 PingCAP 官方和開源社區(qū)進行深入合作的開發(fā)模式。

美團業(yè)務(wù)線眾多，我們根據(jù)業(yè)務(wù)特點及重要程度逐步推進上線，到截稿為止，已經(jīng)上線了 10 個集群，近 200 個物理節(jié)點，大部分是 OLTP 類型的應(yīng)用，除了上線初期遇到了一些小問題，目前均已穩(wěn)定運行。初期上線的集群，已經(jīng)分別服務(wù)于配送、出行、閃付、酒旅等業(yè)務(wù)。雖然 TiDB 的架構(gòu)分層相對比較清晰，服務(wù)也是比較平穩(wěn)和流暢，但在美團當(dāng)前的數(shù)據(jù)量規(guī)模和已有穩(wěn)定的存儲體系的基礎(chǔ)上，推廣新的存儲服務(wù)體系，需要對周邊工具和系統(tǒng)進行一系列改造和適配，從初期探索到整合落地，仍然還需要走很遠的路。下面將從以下幾個方面分別進行介紹：

從 0 到 1 的突破，重點考慮做哪些事情。

如何規(guī)劃實施不同業(yè)務(wù)場景的接入和已有業(yè)務(wù)的遷移。

上線后遇到的一些典型問題介紹。

后續(xù)規(guī)劃和對未來的展望。?

我們對于 TiDB 的定位，前期在于重點解決 MySQL 的單機性能和容量無法線性和靈活擴展的問題，與 MySQL 形成互補。業(yè)界分布式方案很多，我們?yōu)楹芜x擇了 TiDB 呢？考慮到公司業(yè)務(wù)規(guī)模的快速增長，以及公司內(nèi)關(guān)系數(shù)據(jù)庫以 MySQL 為主的現(xiàn)狀，因此我們在調(diào)研階段，對以下技術(shù)特性進行了重點考慮：

協(xié)議兼容 MySQL：這個是必要項。

可在線擴展：數(shù)據(jù)通常要有分片，分片要支持分裂和自動遷移，并且遷移過程要盡量對業(yè)務(wù)無感知。

強一致的分布式事務(wù)：事務(wù)可以跨分片、跨節(jié)點執(zhí)行，并且強一致。

支持二級索引：為兼容 MySQL 的業(yè)務(wù)，這個是必須的。

性能：MySQL 的業(yè)務(wù)特性，高并發(fā)的 OLTP 性能必須滿足。

跨機房服務(wù)：需要保證任何一個機房宕機，服務(wù)能自動切換。

跨機房雙寫：支持跨機房雙寫是數(shù)據(jù)庫領(lǐng)域一大難題，是我們對分布式數(shù)據(jù)庫的一個重要期待，也是美團下一階段重要的需求。

業(yè)界的一些傳統(tǒng)方案雖然支持分片，但無法自動分裂、遷移，不支持分布式事務(wù)，還有一些在傳統(tǒng) MySQL 上開發(fā)一致性協(xié)議的方案，但它無法實現(xiàn)線性擴展，最終我們選擇了與我們的需求最為接近的 TiDB。與 MySQL 語法和特性高度兼容，具有靈活的在線擴容縮容特性，支持 ACID 的強一致性事務(wù)，可以跨機房部署實現(xiàn)跨機房容災(zāi)，支持多節(jié)點寫入，對業(yè)務(wù)又能像單機 MySQL 一樣使用。

針對官方聲稱的以上優(yōu)點，我們進行了大量的研究、測試和驗證。

首先，我們需要知道擴容、Region 分裂轉(zhuǎn)移的細節(jié)、Schema 到 KV 的映射、分布式事務(wù)的實現(xiàn)原理。而 TiDB 的方案，參考了較多的 Google 論文，我們進行了閱讀，這有助于我們理解 TiDB 的存儲結(jié)構(gòu)、事務(wù)算法、安全性等，包括：

Spanner: Google’s Globally-Distributed Database

Large-scale Incremental Processing Using Distributed Transactions and Notifications

In Search of an Understandable Consensus Algorithm

Online, Asynchronous Schema Change in F1

我們也進行了常規(guī)的性能和功能測試，用來與 MySQL 的指標(biāo)進行對比，其中一個比較特別的測試，是證明 3 副本跨機房部署，確實能保證每個機房分布一個副本，從而保證任何一個機房宕機不會導(dǎo)致丟失超過半數(shù)副本。我們從以下幾個點進行了測試：

Raft 擴容時是否支持 Learner 節(jié)點，從而保證單機房宕機不會丟失 2/3 的副本。

TiKV 上的標(biāo)簽優(yōu)先級是否可靠，保證當(dāng)機房的機器不平均時，能否保證每個機房的副本數(shù)依然是絕對平均的。

實際測試，單機房宕機，TiDB 在高并發(fā)下，QPS、響應(yīng)時間、報錯數(shù)量，以及最終數(shù)據(jù)是否有丟失。

手動 Balance 一個 Region 到其他機房，是否會自動回來。

從測試結(jié)果來看，一切都符合我們的預(yù)期。

美團的產(chǎn)品線豐富，業(yè)務(wù)體量也比較大，業(yè)務(wù)對在線存儲的服務(wù)質(zhì)量要求也非常高。因此，從早期做好服務(wù)體系的規(guī)劃非常重要。下面從業(yè)務(wù)接入層、監(jiān)控報警、服務(wù)部署等維度，來分別介紹一下我們所做的工作。

當(dāng)前 MySQL 的業(yè)務(wù)接入方式主要有兩種，DNS 接入和 Zebra 客戶端接入。在前期調(diào)研階段，我們選擇了 DNS + 負載均衡組件的接入方式，TiDB-Server 節(jié)點宕機，15s 可以被負載均衡識別到，簡單且有效。業(yè)務(wù)架構(gòu)如下圖所示：

圖 2 業(yè)務(wù)架構(gòu)圖

后面，我們會逐漸過渡到當(dāng)前大量使用的 Zebra 接入方式來訪問 TiDB，從而保持與訪問 MySQL 的方式一致，一方面減少業(yè)務(wù)改造的成本，另一方面盡量實現(xiàn)從 MySQL 到 TiDB 的透明遷移。

美團目前使用 Mt-Falcon 平臺負責(zé)監(jiān)控報警，通過在 Mt-Falcon 上配置不同的插件，可以實現(xiàn)對多種組件的自定義監(jiān)控。另外也會結(jié)合 Puppet 識別不同用戶的權(quán)限、文件的下發(fā)。只要我們編寫好插件腳本、需要的文件，裝機和權(quán)限控制就可以完成了。監(jiān)控架構(gòu)如下圖所示：

圖 3 監(jiān)控架構(gòu)圖

而 TiDB 有豐富的監(jiān)控指標(biāo)，使用流行的 Prometheus + Grafana，一套集群有 700+ 的 Metric。從官方的架構(gòu)圖可以看出，每個組件會推送自己的 Metric 給 PushGateWay，Prometheus 會直接到 PushGateWay 去抓數(shù)據(jù)。

由于我們需要組件收斂，原生的 TiDB 每個集群一套 Prometheus 的方式不利于監(jiān)控的匯總、分析、配置，而報警已經(jīng)在 Mt-Falcon 上實現(xiàn)的比較好了，在 AlertManager 上再造一個也沒有必要。因此我們需要想辦法把監(jiān)控和報警匯總到 Mt-Falcon 上面，包括如下幾種方式：

方案一：修改源代碼，將 Metric 直接推送到 Falcon，由于 Metric 散落在代碼的不同位置，而且 TiDB 代碼迭代太快，把精力消耗在不停調(diào)整監(jiān)控埋點上不太合適。

方案二：在 PushGateWay 是匯總后的，可以直接抓取，但 PushGateWay 是個單點，不好維護。

方案三：通過各個組件（TiDB、PD、TiKV）的本地 API 直接抓取，優(yōu)點是組件宕機不會影響其他組件，實現(xiàn)也比較簡單。

我們最終選擇了方案三。該方案的難點是需要把 Prometheus 的數(shù)據(jù)格式轉(zhuǎn)化為 Mt-Falcon 可識別的格式，因為 Prometheus 支持 Counter、Gauge、Histogram、Summary 四種數(shù)據(jù)類型，而 Mt-Falcon 只支持基本的 Counter 和 Gauge，同時 Mt-Falcon 的計算表達式比較少，因此需要在監(jiān)控腳本中進行轉(zhuǎn)換和計算。

TiDB 使用 Ansible 實現(xiàn)自動化部署。迭代快，是 TiDB 的一個特點，有問題能快速進行解決，但也造成 Ansible 工程、TiDB 版本更新過快，我們對 Ansible 的改動，也只會增加新的代碼，不會改動已有的代碼。因此線上可能同時需要部署、維護多個版本的集群。如果每個集群一個 Ansible 目錄，造成空間的浪費。

我們采用的維護方式是，在中控機中，每個版本一個 Ansible 目錄，每個版本中通過不同 inventory 文件來維護。這里需要跟 PingCAP 提出的是，Ansible 只考慮了單集群部署，大量部署會有些麻煩，像一些依賴的配置文件，都不能根據(jù)集群多帶帶配置（咨詢官方得知，PingCAP 目前正在基于 Cloud TiDB 打造一站式 HTAP 平臺，會提供批量部署、多租戶等功能，后續(xù)會比較好地解決這個問題）。

隨著線上集群數(shù)量的增加，打造運維平臺提上了日程，而美團對 TiDB 和 MySQL 的使用方式基本相同，因此 MySQL 平臺上具有的大部分組件，TiDB 平臺也需要建設(shè)。典型的底層組件和方案：SQL 審核模塊、DTS、數(shù)據(jù)備份方案等。自動化運維平臺展示如下圖所示：

圖 4 自動化運維平臺展示圖

TiDB 是在線存儲體系中的一環(huán)，它同時也需要融入到公司現(xiàn)有的數(shù)據(jù)流中，因此需要一些工具來做銜接。PingCAP 官方標(biāo)配了相關(guān)的組件。

公司目前 MySQL 和 Hive 結(jié)合的比較重，而 TiDB 要代替 MySQL 的部分功能，需要解決 2 個問題：

MySQL to TiDB

MySQL 到 TiDB 的遷移，需要解決數(shù)據(jù)遷移以及增量的實時同步，也就是 DTS，Mydumper + Loader 解決存量數(shù)據(jù)的同步，官方提供了 DM 工具可以很好的解決增量同步問題。

MySQL 大量使用了自增 ID 作為主鍵。分庫分表 MySQL 合并到 TiDB 時，需要解決自增 ID 沖突的問題。這個通過在 TiDB 端去掉自增 ID 建立自己的唯一主鍵來解決。新版 DM 也提供分表合并過程主鍵自動處理的功能。

Hive to TiDB & TiDB to Hive

Hive to TiDB 比較好解決，這體現(xiàn)了 TiDB 和 MySQL 高度兼容的好處，insert 語句可以不用調(diào)整，基于 Hive to MySQL 簡單改造即可。

TiDB to Hive 則需要基于官方 Pump + Drainer 組件，Drainer 可以消費到 Kafka、MySQL、TiDB，我們初步考慮用圖 5 中的方案通過使用 Drainer 的 Kafka 輸出模式同步到 Hive。

圖 5 TiDB to Hive 方案圖

對于初期上線的業(yè)務(wù)，我們比較謹慎，基本的原則是：離線業(yè)務(wù) -> 非核心業(yè)務(wù) -> 核心業(yè)務(wù)。TiDB 已經(jīng)發(fā)布兩年多，且前期經(jīng)歷了大量的測試，我們也深入了解了其它公司的測試和使用情況，可以預(yù)期的是 TiDB 上線會比較穩(wěn)定，但依然遇到了一些小問題。總體來看，在安全性、數(shù)據(jù)一致性等關(guān)鍵點上沒有出現(xiàn)問題。其他一些性能抖動問題，參數(shù)調(diào)優(yōu)的問題，也都得到了快速妥善的解決。這里給 PingCAP 的同學(xué)點個大大的贊，問題響應(yīng)速度非?？?，與我們美團內(nèi)部研發(fā)的合作也非常融洽。

我們上線的最大的一個業(yè)務(wù)，每天有數(shù)百 G 的寫入量，在前期，我們也遇到了較多的問題。

業(yè)務(wù)場景：

穩(wěn)定的寫入，每個事務(wù)操作 100~200 行不等，每秒 6W 的數(shù)據(jù)寫入。

每天的寫入量超過 500G，以后會逐步提量到每天 3T。

每 15 分鐘的定時讀 Job，5000 QPS（高頻量?。?。

不定時的查詢（低頻量大）。?

之前使用 MySQL 作為存儲，但 MySQL 到達了容量和性能瓶頸，而業(yè)務(wù)的容量未來會 10 倍的增長。初期調(diào)研測試了 ClickHouse，滿足了容量的需求，測試發(fā)現(xiàn)運行低頻 SQL 沒有問題，但高頻 SQL 的大并發(fā)查詢無法滿足需求，只在 ClickHouse 跑全量的低頻 SQL 又會 overkill，最終選擇使用 TiDB。

測試期間模擬寫入了一天的真實數(shù)據(jù)，非常穩(wěn)定，高頻低頻兩種查詢也都滿足需求，定向優(yōu)化后 OLAP 的 SQL 比 MySQL 性能提高四倍。但上線后，陸續(xù)發(fā)現(xiàn)了一些問題，典型的如下：

TiKV 底層有 2 個 RocksDB 作為存儲。新寫的數(shù)據(jù)寫入 L0 層，當(dāng) RocksDB 的 L0 層數(shù)量達到一定數(shù)量，就會發(fā)生減速，更高則發(fā)生 Stall，用來自我保護。TiKV 的默認配置：

level0-slowdown-writes-trigger = 20

level0-stop-writes-trigger = 36?

遇到過的，發(fā)生 L0 文件過多可能的原因有 2 個：

寫入量大，Compact 完不成。

Snapshot 一直創(chuàng)建不完，導(dǎo)致堆積的副本一下釋放，RocksDB-Raft 創(chuàng)建大量的 L0 文件，監(jiān)控展示如下圖所示：

圖 6 TiKV 發(fā)生 Write Stall 監(jiān)控展示圖

我們通過以下措施，解決了 Write Stall 的問題：

減緩 Raft Log Compact 頻率（增大 raft-log-gc-size-limit、raft-log-gc-count-limit）

加快 Snapshot 速度（整體性能、包括硬件性能）

max-sub-compactions 調(diào)整為 3

max-background-jobs 調(diào)整為 12

level 0 的 3 個 Trigger 調(diào)整為 16、32、64

現(xiàn)在 TiDB 的 GC 對于每個 kv-instance 是單線程的，當(dāng)業(yè)務(wù)刪除數(shù)據(jù)的量非常大時，會導(dǎo)致 GC 速度較慢，很可能 GC 的速度跟不上寫入。

目前可以通過增多 TiKV 個數(shù)來解決，長期需要靠 GC 改為多線程執(zhí)行，官方對此已經(jīng)實現(xiàn)，即將發(fā)布。

業(yè)務(wù)上線初期，insert 的響應(yīng)時間 80 線（Duration 80 By Instance）在 20ms 左右，隨著運行時間增加，發(fā)現(xiàn)響應(yīng)時間逐步增加到 200ms+。期間排查了多種可能原因，定位在由于 Region 數(shù)量快速上漲，Raftstore 里面要做的事情變多了，而它又是單線程工作，每個 Region 定期都要 heartbeat，帶來了性能消耗。tikv-raft propose wait duration 指標(biāo)持續(xù)增長。

解決問題的辦法：

臨時解決。

增加 Heartbeat 的周期，從 1s 改為 2s，效果比較明顯，監(jiān)控展示如下圖所示：

圖 7 insert 響應(yīng)時間優(yōu)化前后對比圖

徹底解決。

需要減少 Region 個數(shù)，Merge 掉空 Region，官方在 2.1 版本中已經(jīng)實現(xiàn)了 Region Merge 功能，我們在升級到 2.1 后，得到了徹底解決。

另外，等待 Raftstore 改為多線程，能進一步優(yōu)化。（官方回復(fù)相關(guān)開發(fā)已基本接近尾聲，將于 2.1 的下一個版本發(fā)布。）

DBA Truncate 一張大表后，發(fā)現(xiàn) 2 個現(xiàn)象，一是空間回收較慢，二是最終也沒有完全回收。

由于底層 RocksDB 的機制，很多數(shù)據(jù)落在 Level 6 上，有可能清不掉。這個需要打開 cdynamic-level-bytes 會優(yōu)化 Compaction 的策略，提高 Compact 回收空間的速度。

由于 Truncate 使用 delete_files_in_range 接口，發(fā)給 TiKV 去刪 SST 文件，這里只刪除不相交的部分，而之前判斷是否相交的粒度是 Region，因此導(dǎo)致了大量 SST 無法及時刪除掉。

考慮 Region 獨立 SST 可以解決交叉問題，但是隨之帶來的是磁盤占用問題和 Split 延時問題。

考慮使用 RocksDB 的 DeleteRange 接口，但需要等該接口穩(wěn)定。

目前最新的 2.1 版本優(yōu)化為直接使用 DeleteFilesInRange 接口刪除整個表占用的空間，然后清理少量殘留數(shù)據(jù)，目前已經(jīng)解決。

為了解決 region 過多的問題，我們在升級 2.1 版本后，開啟了 region merge 功能，但是 TiDB 的響應(yīng)時間 80 線（Duration 80 By Instance）依然沒有恢復(fù)到當(dāng)初，保持在 50ms 左右，排查發(fā)現(xiàn) KV 層返回的響應(yīng)時間還很快，和最初接近，那么就定位了問題出現(xiàn)在 TiDB 層。研發(fā)人員和 PingCAP 定位在產(chǎn)生執(zhí)行計劃時行為和 2.0 版本不一致了，目前已經(jīng)優(yōu)化。

除了分析查詢量大的離線業(yè)務(wù)場景，美團還有很多分庫分表的場景，雖然業(yè)界有很多分庫分表的方案，解決了單機性能、存儲瓶頸，但是對于業(yè)務(wù)還是有些不友好的地方：

業(yè)務(wù)無法友好的執(zhí)行分布式事務(wù)。

跨庫的查詢，需要在中間層上組合，是比較重的方案。

單庫如果容量不足，需要再次拆分，無論怎樣做，都很痛苦。

業(yè)務(wù)需要關(guān)注數(shù)據(jù)分布的規(guī)則，即使用了中間層，業(yè)務(wù)心里還是沒底。

因此很多分庫分表的業(yè)務(wù)，以及即將無法在單機承載而正在設(shè)計分庫分表方案的業(yè)務(wù)，主動找到了我們，這和我們對于 TiDB 的定位是相符的。這些業(yè)務(wù)的特點是 SQL 語句小而頻繁，對一致性要求高，通常部分數(shù)據(jù)有時間屬性。在測試及上線后也遇到了一些問題，不過目前基本都有了解決辦法。

業(yè)務(wù)偶爾報出 privilege check fail。

是由于業(yè)務(wù)在 JDBC 設(shè)置了 QueryTimeout，SQL 運行超過這個時間，會發(fā)行一個 kill query 命令，而 TiDB 執(zhí)行這個命令需要 Super 權(quán)限，業(yè)務(wù)是沒有權(quán)限的。其實 kill 自己的查詢，并不需要額外的權(quán)限，目前已經(jīng)解決了這個問題：
https://github.com/pingcap/tidb/pull/7003，不再需要 Super 權(quán)限，已在 2.0.5 上線。

TiDB 的物理優(yōu)化階段需要依靠統(tǒng)計信息。在 2.0 版本統(tǒng)計信息的收集從手動執(zhí)行，優(yōu)化為在達到一定條件時可以自動觸發(fā)：

數(shù)據(jù)修改比例達到 tidb_auto_analyze_ratio。

表一分鐘沒有變更（目前版本已經(jīng)去掉這個條件）。

但是在沒有達到這些條件之前統(tǒng)計信息是不準的，這樣就會導(dǎo)致物理優(yōu)化出現(xiàn)偏差，在測試階段（2.0 版本）就出現(xiàn)了這樣一個案例：業(yè)務(wù)數(shù)據(jù)是有時間屬性的，業(yè)務(wù)的查詢有 2 個條件，比如：時間+商家 ID，但每天上午統(tǒng)計信息可能不準，當(dāng)天的數(shù)據(jù)已經(jīng)有了，但統(tǒng)計信息認為沒有。這時優(yōu)化器就會建議使用時間列的索引，但實際上商家 ID 列的索引更優(yōu)化。這個問題可以通過增加 Hint 解決。

在 2.1 版本對統(tǒng)計信息和執(zhí)行計劃的計算做了大量的優(yōu)化，也穩(wěn)定了基于 Query Feedback 更新統(tǒng)計信息，也用于更新直方圖和 Count-Min Sketch，非常期待 2.1 的 GA。

經(jīng)過前期的測試、各方的溝通協(xié)調(diào)，以及近半年對 TiDB 的使用，我們看好 TiDB 的發(fā)展，也對未來基于 TiDB 的合作充滿信心。

接下來，我們會加速推進 TiDB 在更多業(yè)務(wù)系統(tǒng)中的使用，同時也將 TiDB 納入了美團新一代數(shù)據(jù)庫的戰(zhàn)略選型中。當(dāng)前，我們已經(jīng)全職投入了 3 位 DBA 同學(xué)和多位存儲計算專家，從底層的存儲，中間層的計算，業(yè)務(wù)層的接入，再到存儲方案的選型和布道，進行全方位和更深入的合作。

長期來看，結(jié)合美團不斷增長的業(yè)務(wù)規(guī)模，我們將與 PingCAP 官方合作打造更強大的生態(tài)體系：

Titan：Titan 是 TiDB 下一步比較大的動作，也是我們非常期待的下一代存儲引擎，它對大 Value 支持會更友好，將解決我們單行大小受限，單機 TiKV 最大支持存儲容量的問題，大大提升大規(guī)模部署的性價比。

Cloud TiDB （Based on Docker & K8s）：云計算大勢所趨，PingCAP 在這塊也布局比較早，今年 8 月份開源了 TiDB Operator，Cloud TiDB 不僅實現(xiàn)了數(shù)據(jù)庫的高度自動化運維，而且基于 Docker 硬件隔離，實現(xiàn)了數(shù)據(jù)庫比較完美的多租戶架構(gòu)。我們和官方同學(xué)溝通，目前他們的私有云方案在國內(nèi)也有重要體量的 POC，這也是美團看重的一個方向。

TiDB HTAP Platform：PingCAP 在原有 TiDB Server 計算引擎的基礎(chǔ)上，還構(gòu)建 TiSpark 計算引擎，和他們官方溝通，他們在研發(fā)了一個基于列的存儲引擎，這樣就形成了下層行、列兩個存儲引擎、上層兩個計算引擎的完整混合數(shù)據(jù)庫（HTAP），這個架構(gòu)不僅大大的節(jié)省了核心業(yè)務(wù)數(shù)據(jù)在整個公司業(yè)務(wù)周期里的副本數(shù)量，還通過收斂技術(shù)棧，節(jié)省了大量的人力成本、技術(shù)成本、機器成本，同時還解決了困擾多年的 OLAP 的實效性。后面我們也會考慮將一些有實時、準實時的分析查詢系統(tǒng)接入 TiDB。

圖 8 TiDB HTAP Platform 整體架構(gòu)圖

后續(xù)的物理備份方案，跨機房多寫等也是我們接下來逐步推進的場景，總之，我們堅信未來 TiDB 在美團的使用場景會越來越多，發(fā)展也會越來越好。

目前，TiDB 在業(yè)務(wù)層面、技術(shù)合作層面都已經(jīng)在美團揚帆起航，美團點評將攜手 PingCAP 開啟新一代數(shù)據(jù)庫深度實踐、探索之旅。后續(xù)，還有美團點評架構(gòu)存儲團隊針對 TiDB 源碼研究和改進的系列文章，敬請期待。

應(yīng)鋼，美團點評研究員，數(shù)據(jù)庫專家。曾就職于百度、新浪、去哪兒網(wǎng)等，10年數(shù)據(jù)庫自動化運維開發(fā)、數(shù)據(jù)庫性能優(yōu)化、大規(guī)模數(shù)據(jù)庫集群技術(shù)保障和架構(gòu)優(yōu)化經(jīng)驗。精通主流的SQL與NoSQL系統(tǒng)，現(xiàn)專注于公司業(yè)務(wù)在NewSQL領(lǐng)域的創(chuàng)新和落地。

李坤，2018年初加入美團，美團點評數(shù)據(jù)庫專家，多年基于MySQL、Hbase、Oracle的架構(gòu)設(shè)計和維護、自動化開發(fā)經(jīng)驗，目前主要負責(zé)分布式數(shù)據(jù)庫Blade的推動和落地，以及平臺和周邊組件的建設(shè)

昌俊，美團點評數(shù)據(jù)庫專家，曾就職于BOCO、去哪兒網(wǎng)，6年MySQL DBA從業(yè)經(jīng)歷，積累了豐富的數(shù)據(jù)庫架構(gòu)設(shè)計和性能優(yōu)化、自動化開發(fā)經(jīng)驗。目前專注于TiDB在美團點評業(yè)務(wù)場景的改造和落地。