1. 程式人生 > >TiDB at 豐巢:嚐鮮分散式資料庫

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 的改造,只是豐巢對於分散式資料技術探索的一小步,未來豐巢會將更多的分散式技術,引入到更多的業務系統,打造更加極致的產品和服務。