作者：豐巢技術團隊
隨着豐巢業務系統快速增長，其核心繫統的數據量，早就跨越了億級別，而且每年增量仍然在飛速發展。整個核心系統隨着數據量的壓力增長，不但系統架構複雜度急劇增長，數據架構更加複雜，傳統的單節點數據庫，已經日漸不能滿足豐巢的需求，當單表數量上億的時候，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 的改造，只是豐巢對於分佈式數據技術探索的一小步，未來豐巢會將更多的分佈式技術，引入到更多的業務系統，打造更加極致的產品和服務。
