TiDB at 豐巢：嚐鮮分佈式數據庫

做者：豐巢技術團隊

隨着豐巢業務系統快速增加，其核心繫統的數據量，早就跨越了億級別，並且每一年增量仍然在飛速發展。整個核心系統隨着數據量的壓力增加，不但系統架構複雜度急劇增加，數據架構更加複雜，傳統的單節點數據庫，已經日漸不能知足豐巢的需求，當單表數量上億的時候，Oracle 還能勉強抗住，而 MySQL 到單表千萬級別的時候就難以支撐，須要進行分表分庫。爲此，一款高性能的分佈式數據庫，日漸成爲剛需。

思考

在互聯網公司業務量增大以後，並行擴展是最經常使用、最簡單、最實時的手段。例如負載均衡設備拆流量，讓海量流量變成每一個機器能夠承受的少許流量，而且經過集羣等方式支撐起來整個業務。因而當數據庫扛不住的時候也進行拆分。

但有狀態數據和無狀態數據不一樣，當數據進行拆分的時候，會發生數據分區，而整個系統又要高可用狀態下進行，因而數據的一致性變成了犧牲品，大量的核對工具在系統之間跑着保證着最終的一致性。在業務上，可能業務同窗常常會遇到分過庫的同窗說，這個需求作不了，那個需求作不了，若是有 sql 經驗的業務同窗可能會有疑問不就是一條 sql 的事情麼，其實這就是分庫分表後遺症。

爲此，咱們須要有個數據庫幫咱們解決以上問題，它的特性應該是：

• 數據強一致：支持完整的 ACID

• 不分表分庫：不管多少數據咱們只管插入不須要關心啥時候擴容，會不會 有瓶頸

• 數據高可用：當咱們某臺數據庫的少部分機器磁盤或者其餘掛了的時候，咱們業務上能夠無感知，甚至某個城市機房發生災難的時候還能夠持續提供服務，數據不丟失

• 複雜 SQL 功能：基本上單庫的 SQL，均可以在這個數據庫上運行，不須要修改或者些許修改

• 高性能：在知足高 QPS 的同時，保證比較低的延時

選型

根據以上指望進行分析，咱們分析了目前市面上存在的 NewSQL 分佈式數據庫，列表以下：

在綜合考慮了開源協議，成熟度，可控度，性能，服務支撐等綜合因素以後，咱們選擇了 TiDB，它主要優點以下：

• 高度兼容 MySQL

  大多數狀況下，無需修改代碼便可從 MySQL 輕鬆遷移至 TiDB，分庫分表後的 MySQL 集羣亦可經過 TiDB 工具進行實時遷移。

• 水平彈性擴展

  經過簡單地增長新節點便可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕鬆鬆應對高併發、海量數據場景。

• 分佈式事務

  TiDB 100% 支持標準的 ACID 事務。

• 金融級別的高可用性

  相比於傳統主從（M-S）複製方案，基於 Raft 的多數派選舉協議能夠提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，能夠實現故障的自動恢復（auto-failover），無需人工介入。

基於如上的緣由，咱們選擇了 TiDB，做爲豐巢的核心繫統的分佈式數據庫，來取代   Oracle 和 MySQL。

評估

1. 性能測試

TiDB 的基準測試，使用的工具是 sysbanch 進行測試，使用了 8 張基礎數據爲一千萬的表，分別測試了 insert，select，oltp 和 delete 腳本獲得數據以下，查詢的 QPS 達到了驚人的 14 萬每秒，而插入也穩定在 1 萬 4 每秒。

核心服務器配置：

測試結果：

經過～

2. 功能測試

經過～

接入

由於是核心系統，安全起見，咱們採起了多種方案保證驗證項目接入的可靠性，保證不影響業務。

1. 項目選擇

在尋找第一個接入項目的時候，咱們以一下 4 個特徵，進行了選擇。

最終，咱們選擇了推送服務。由於推送服務是豐巢用來發送取件通知的核心服務，量很是大，但邏輯簡單，並且有備選外部推送方案，因此即使萬一出現問題，而不會影響用戶。

2. 代碼修改

**由於 TiDB 是徹底兼容 MySQL 語法的，因此在這個項目的接入過程當中，咱們對代碼的修改是很細微的。**SQL 基本零改動，主要是外圍代碼，包括：

• 異步接口修改，數據異步化入庫

• 同步接口修改，實現異常熔斷

• 中止內嵌數據遷移代碼

以上三點，保證了整個系統在不強依賴於數據庫，而且能在高併發的狀況下經過異步落庫保護數據庫不被壓垮，而且在數據庫發生問題的時候，核心業務能夠正常進行下去。

效果

1. 查詢能力

接入 TiDB 以後，原先按照時間維度來拆分的十幾個分表，變成了一張大表。最明顯的變化，是在大數據量下，數據查詢能力有了顯著的提高。

2. 監控能力

TiDB 擁有很完善的監控平臺，能夠直觀的看到容量，以及節點狀態。

還能瞭解每一個節點負載和 sql 執行的延時：

固然還能瞭解所在機器上的位置，CPU 內存等負載狀況：

網絡狀態也能清晰的監控到：

全部這些能讓團隊能分析出來有問題的 sql，以及數據庫自己的問題。

小結

TiDB 的接入過程，總體仍是很是順利的，因爲以前作了不少接入的保障工做，當天切換流量到 TiDB 的過程只用了 10 分鐘的時間，在此也要感謝 TiDB 對於 MySQL 語法的兼容性的支持，以及 PingCAP 提供的各類有用的工具。到目前爲止，系統的穩定運行了一個多月，很好的知足了豐巢的業務需求。

TiDB 的改造完成以後，豐巢推送服務對大部分消息進行了落地和查詢，截止目前爲止，推送服務最大的日落地量已經達到了 5 千萬，而若是如今推送服務還使用的仍是 MySQL 的方案，就須要上各類的分庫分表方案，不少細緻的業務就沒法或者難以開展。

這次 TiDB 的改造，只是豐巢對於分佈式數據技術探索的一小步，將來豐巢會將更多的分佈式技術，引入到更多的業務系統，打造更加極致的產品和服務。