摘要：為此，一款高性能的分布式數(shù)據(jù)庫，日漸成為剛需。基于如上的原因，我們選擇了，作為豐巢的核心系統(tǒng)的分布式數(shù)據(jù)庫，來取代和。

作者：豐巢技術(shù)團(tuán)隊(duì)

隨著豐巢業(yè)務(wù)系統(tǒng)快速增長(zhǎng)，其核心系統(tǒng)的數(shù)據(jù)量，早就跨越了億級(jí)別，而且每年增量仍然在飛速發(fā)展。整個(gè)核心系統(tǒng)隨著數(shù)據(jù)量的壓力增長(zhǎng)，不但系統(tǒng)架構(gòu)復(fù)雜度急劇增長(zhǎng)，數(shù)據(jù)架構(gòu)更加復(fù)雜，傳統(tǒng)的單節(jié)點(diǎn)數(shù)據(jù)庫，已經(jīng)日漸不能滿足豐巢的需求，當(dāng)單表數(shù)量上億的時(shí)候，Oracle 還能勉強(qiáng)抗住，而 MySQL 到單表千萬級(jí)別的時(shí)候就難以支撐，需要進(jìn)行分表分庫。為此，一款高性能的分布式數(shù)據(jù)庫，日漸成為剛需。

在互聯(lián)網(wǎng)公司業(yè)務(wù)量增大之后，并行擴(kuò)展是最常用、最簡(jiǎn)單、最實(shí)時(shí)的手段。例如負(fù)載均衡設(shè)備拆流量，讓海量流量變成每個(gè)機(jī)器可以承受的少量流量，并且通過集群等方式支撐起來整個(gè)業(yè)務(wù)。于是當(dāng)數(shù)據(jù)庫扛不住的時(shí)候也進(jìn)行拆分。

但有狀態(tài)數(shù)據(jù)和無狀態(tài)數(shù)據(jù)不同，當(dāng)數(shù)據(jù)進(jìn)行拆分的時(shí)候，會(huì)發(fā)生數(shù)據(jù)分區(qū)，而整個(gè)系統(tǒng)又要高可用狀態(tài)下進(jìn)行，于是數(shù)據(jù)的一致性變成了犧牲品，大量的核對(duì)工具在系統(tǒng)之間跑著保證著最終的一致性。在業(yè)務(wù)上，可能業(yè)務(wù)同學(xué)經(jīng)常會(huì)遇到分過庫的同學(xué)說，這個(gè)需求做不了，那個(gè)需求做不了，如果有 sql 經(jīng)驗(yàn)的業(yè)務(wù)同學(xué)可能會(huì)有疑問不就是一條 sql 的事情么，其實(shí)這就是分庫分表后遺癥。

為此，我們需要有個(gè)數(shù)據(jù)庫幫我們解決以上問題，它的特性應(yīng)該是：

數(shù)據(jù)強(qiáng)一致：支持完整的 ACID

不分表分庫：無論多少數(shù)據(jù)我們只管插入不需要關(guān)心啥時(shí)候擴(kuò)容，會(huì)不會(huì) 有瓶頸

數(shù)據(jù)高可用：當(dāng)我們某臺(tái)數(shù)據(jù)庫的少部分機(jī)器磁盤或者其他掛了的時(shí)候，我們業(yè)務(wù)上可以無感知，甚至某個(gè)城市機(jī)房發(fā)生災(zāi)難的時(shí)候還可以持續(xù)提供服務(wù)，數(shù)據(jù)不丟失

復(fù)雜 SQL 功能：基本上單庫的 SQL，都可以在這個(gè)數(shù)據(jù)庫上運(yùn)行，不需要修改或者些許修改

高性能：在滿足高 QPS 的同時(shí)，保證比較低的延時(shí)

根據(jù)以上期望進(jìn)行分析，我們分析了目前市面上存在的 NewSQL 分布式數(shù)據(jù)庫，列表如下：

在綜合考慮了開源協(xié)議，成熟度，可控度，性能，服務(wù)支撐等綜合因素之后，我們選擇了 TiDB，它主要優(yōu)勢(shì)如下：

高度兼容 MySQL

大多數(shù)情況下，無需修改代碼即可從?MySQL?輕松遷移至 TiDB，分庫分表后的 MySQL 集群亦可通過 TiDB 工具進(jìn)行實(shí)時(shí)遷移。? ??

水平彈性擴(kuò)展

通過簡(jiǎn)單地增加新節(jié)點(diǎn)即可實(shí)現(xiàn) TiDB 的水平擴(kuò)展，按需擴(kuò)展吞吐或存儲(chǔ)，輕松松應(yīng)對(duì)高并發(fā)、海量數(shù)據(jù)場(chǎng)景。

分布式事務(wù)?

TiDB 100% 支持標(biāo)準(zhǔn)的 ACID 事務(wù)。

金融級(jí)別的高可用性

相比于傳統(tǒng)主從（M-S）復(fù)制方案，基于 Raft 的多數(shù)派選舉協(xié)議可以提供金融級(jí)的 100% 數(shù)據(jù)強(qiáng)一致性保證，且在不丟失大多數(shù)副本的前提下，可以實(shí)現(xiàn)故障的自動(dòng)恢復(fù)（auto-failover），無需人工介入。

基于如上的原因，我們選擇了 TiDB，作為豐巢的核心系統(tǒng)的分布式數(shù)據(jù)庫，來取代? ?Oracle 和 MySQL。

TiDB 的基準(zhǔn)測(cè)試，使用的工具是 sysbanch 進(jìn)行測(cè)試，使用了 8 張基礎(chǔ)數(shù)據(jù)為一千萬的表，分別測(cè)試了 insert，select，oltp 和 delete 腳本得到數(shù)據(jù)如下，查詢的 QPS 達(dá)到了驚人的 14 萬每秒，而插入也穩(wěn)定在 1 萬 4 每秒。

核心服務(wù)器配置：

測(cè)試結(jié)果：

通過～

通過～

因?yàn)槭呛诵南到y(tǒng)，安全起見，我們采取了多種方案保證驗(yàn)證項(xiàng)目接入的可靠性，保證不影響業(yè)務(wù)。

在尋找第一個(gè)接入項(xiàng)目的時(shí)候，我們以一下 4 個(gè)特征，進(jìn)行了選擇。

最終，我們選擇了推送服務(wù)。因?yàn)橥扑头?wù)是豐巢用來發(fā)送取件通知的核心服務(wù)，量非常大，但邏輯簡(jiǎn)單，而且有備選外部推送方案，所以即便萬一出現(xiàn)問題，而不會(huì)影響用戶。

因?yàn)?TiDB 是完全兼容 MySQL 語法的，所以在這個(gè)項(xiàng)目的接入過程中，我們對(duì)代碼的修改是很細(xì)微的。SQL 基本零改動(dòng)，主要是外圍代碼，包括：

異步接口修改，數(shù)據(jù)異步化入庫

同步接口修改，實(shí)現(xiàn)異常熔斷

停止內(nèi)嵌數(shù)據(jù)遷移代碼

以上三點(diǎn)，保證了整個(gè)系統(tǒng)在不強(qiáng)依賴于數(shù)據(jù)庫，并且能在高并發(fā)的情況下通過異步落庫保護(hù)數(shù)據(jù)庫不被壓垮，并且在數(shù)據(jù)庫發(fā)生問題的時(shí)候，核心業(yè)務(wù)可以正常進(jìn)行下去。

接入 TiDB 之后，原先按照時(shí)間維度來拆分的十幾個(gè)分表，變成了一張大表。最明顯的變化，是在大數(shù)據(jù)量下，數(shù)據(jù)查詢能力有了顯著的提升。

TiDB 擁有很完善的監(jiān)控平臺(tái)，可以直觀的看到容量，以及節(jié)點(diǎn)狀態(tài)。

還能了解每個(gè)節(jié)點(diǎn)負(fù)載和 sql 執(zhí)行的延時(shí)：

當(dāng)然還能了解所在機(jī)器上的位置，CPU 內(nèi)存等負(fù)載情況：

網(wǎng)絡(luò)狀態(tài)也能清晰的監(jiān)控到：

所有這些能讓團(tuán)隊(duì)能分析出來有問題的 sql，以及數(shù)據(jù)庫本身的問題。

TiDB 的接入過程，整體還是非常順利的，由于之前做了很多接入的保障工作，當(dāng)天切換流量到 TiDB 的過程只用了 10 分鐘的時(shí)間，在此也要感謝 TiDB 對(duì)于 MySQL 語法的兼容性的支持，以及 PingCAP 提供的各種有用的工具。到目前為止，系統(tǒng)的穩(wěn)定運(yùn)行了一個(gè)多月，很好的滿足了豐巢的業(yè)務(wù)需求。

TiDB 的改造完成之后，豐巢推送服務(wù)對(duì)大部分消息進(jìn)行了落地和查詢，截止目前為止，推送服務(wù)最大的日落地量已經(jīng)達(dá)到了 5 千萬，而如果現(xiàn)在推送服務(wù)還使用的還是 MySQL 的方案，就需要上各種的分庫分表方案，很多細(xì)致的業(yè)務(wù)就無法或者難以開展。

此次 TiDB 的改造，只是豐巢對(duì)于分布式數(shù)據(jù)技術(shù)探索的一小步，未來豐巢會(huì)將更多的分布式技術(shù)，引入到更多的業(yè)務(wù)系統(tǒng)，打造更加極致的產(chǎn)品和服務(wù)。