TiDB 在鳳凰網新聞內容業務的創新實踐

背景

鳳凰網（紐交所上市公司，代碼：FENG) 是全球領先的跨平台網路新媒體公司，整合旗下綜合門戶鳳凰網、手機鳳凰網和鳳凰視頻三大平台，秉承"中華情懷，全球視野，兼容開放，進步力量"的媒體理念， 為主流華人提供互聯網、無線通信、電視網的三網融合無縫銜接的新媒體優質內容與服務。

在媒體行業，新聞內容就是核心的業務數據，我們需要一個穩定的、具有高可用的、易水平擴展的數據存儲系統，來存放公司核心數據，在最早，我們採用比較流行的 MySQL 來存儲各個業務模塊的內容，通過主從切換的方式進行高可用，但隨著數據量的增加，MySQL 單機容量成為了瓶頸，傳統的基於 MySQL 分片方案在實現及運維都需要比較昂貴的成本，同時 MySQL 主流主從切換方案由於機制問題，在判斷「主庫真死」，「新主庫選舉」及「新路由信息廣播」上都存在一些不足，整體時間消耗比較大，並不能達到公司核心業務的高可用要求。於是，我們不得不尋找新的解決方案。

選擇 TiDB

前期方案選擇

在選擇評估初期，我們主要有以下幾個考慮點：

1、支持業務彈性的水平擴容與縮容；

2、滿足業務故障自恢復的高可用；

3、支持 MySQL 便捷穩定的遷移，不影響線上業務；

4、支持 SQL，盡量少的改動代碼；

5、使用上、運維上要足夠優化，最好支持在線 DDL。

在尋找的道路中，我們驚喜的發現了 TiDB — 中國人研發主導的開源分散式資料庫。

資料庫容量及擴展

記得有這樣一句話：「單機 MySQL 能解決的問題，不要使用 TiDB ！」，我們原有的數據存儲存放於多個 MySQL 資料庫中。誠然，對於數據量小的庫來說，一些常見的點查、範圍查 MySQL 的性能要比 TiDB 的性能好，如果不考慮擴張的問題，短期內使用主從 MySQL 比使用 TiDB 更滿足我們的線上需求，但是，即使如此，我們也不得不考慮成本問題。將多套線上的主從 MySQL 遷移到 TiDB，更能充分利用伺服器資源，減少資源的浪費。而對於很多業務來說，擴張問題是不可能迴避的，對數據日益增長的資料庫來說，單表響應時間會越來越長，而分庫分表的成本過高，代碼需要改動和測試，即使業務上能接受這一次的操作，那下次擴容呢？TiDB 通過底層自動進行分片幫我們解決了這個問題，同時業務量的增加或減少可以通過添加減少節點來處理，代碼上基本無改動，這也是我們所期望的。

高可用

對於原有的主從 MySQL，並沒有配置高可用，我們也對 MHA 等第三方工具做過調研，在發生主從切換後，在新路由信息分發這塊也依賴修改網路配置或者資料庫中間件（DBproxy），有一定的時間成本，雖然業界有很多中間件方案，但也很多問題和技術成本，所以這個方向並不是我們首選，之前的方式是一旦 MySQL 主資料庫宕機，我們通過內部的監控系統獲知，再進行更改 Keepalived + HAproxy 配置，即使人為響應非常及時，其影響的時間也早已超過業務的容忍。而選擇天然的多節點 TiDB 自然就避免了這一點，配合網路 HAproxy 完全實現了 DB 層面的高可用。前一段時間，我們內部監控系統升級，其中一台機器沒有對 TiKV 添加監控，而該 TiKV 節點由於硬體原因服務宕了幾天，我們業務上也未感知，當然這是我們的失誤，但是也側面反應了 TiDB 自身的高可用機制。

圖：TiDB 天然高可用架構圖

OSC 問題

眾所周知，一個可編程的內容管理平台，增加欄位是再正常不過的業務場景，雖然 MySQL 5.7 已經支持 Online DDL ，但實際操作還有很多限制，並且經常性導致從庫延遲，TiDB 支持在線 DDL，加欄位的過程是非阻塞的，平滑的，業務無感知的，這也是我們選擇它的一個重要原因。

遷移 TiDB

MySQL 數據遷移到 TiDB 上，我們使用 mydumper、loader 對數據導入導出。而後續數據的增量同步，PingCAP 公司提供了 Syncer 工具回放 MySQL 傳來的 Binlog 日誌來模擬 MySQL 的 Slave。讓我們感到驚喜的是，它支持多個 MySQL 同時同步到一個 TiDB ，剛開始，我們就採用這種方式來搭建環境，這種便捷的方案可以把我們的精力從數據遷移中解放出來，更多關注在業務測試和試用上，經過完善的業務測試後， 我們發現 TiDB 高度兼容 MySQL，於是我們逐步將每個庫流量切到 TiDB 上，整個數據遷移、流量遷移都非常友好便捷。實際遷移過程中，只遇到了由於部分原有 MySQL 版本過低導致 Binlog 格式不兼容的問題，除此之外其他都很順利。

圖：多源實時同步匯總架構

節點遷移

TiDB 的線上節點遷移。我們線上的部分 TiDB 是使用 Binary 部署的，且版本過老（2016 年的版本），無法進行及時的自動化升級，因此當我們涉及到機房遷移的時候，會擔心是否會影響服務。好在遷移涉及的是無狀態的 TiDB 節點和存儲元數據的 PD 節點，在對 PD 節點一上一下逐步增加減少驗證無誤後，啟動新機房中的 TiDB 節點，經 Haproxy 層灰度上線幾台後，下掉原有的 TiDB 節點，完成遷移。

官方強力支持

當然，雖然官方提供的遷移方案很友好，但在學習了解、實際操作階段也免不了磕磕絆絆，之前很長一段時間內我們並沒有與 PingCAP 公司取得聯繫，但當我們出現遷移問題的時候，我們選擇求助官方，他們非常迅速的響應了我們，解決了線上遷移因 etcd 導致的 PD 節點去除故障，而且還安排了架構師來我們公司進行技術交流，錦上添花不如雪中送炭，當時我們在與官方人員溝通時，深深體會到了這一點。

TiDB 資料庫的穩定性還是非常不錯的，在我們和官方取得聯繫的時候，我們使用的 beta4 版本也已穩定運行了近 220 天。

TiDB 目前環境

目前我司有三套 TiDB 在使用，均為 OLTP 業務。其中前兩套使用 Binary 安裝的遠古版本（beta4），第三套才是TiDB GA 版本，通過官方 Ansible 進行的部署。

在與官方溝通中獲知，兩套遠古版本（beta4）由於距離現有版本太多需要進行遷移升級，官方也十分願意為我們提供技術支持，在此，就先謝過官方的幫助，顯然，對我們來說後續也少不了麻煩。

一點吐槽

TiDB 的出現，幫我們跳過了傳統的 Sharding + proxy 的路線，給我們節省了巨大的技術成本，我們對 TiDB 非常的鐘愛，但在接觸、使用 TiDB 過程中，我們也遇到一些問題。即使官方對於伺服器配置有明確的要求（SSD 以上硬碟），但對我們公司內來說，剛開始很難申請到高性能的機器來進行 TiDB 功能性測試，和學習、熟悉 TiDB 的搭建、擴容、遷移等操作，於是在剛開始，我們拿幾台低性能的測試機，使用 loader 導入數據進而進行增量測試的時候，出現了報錯，TiDB 的報錯信息並沒有提醒我這是由於機器性能低引起的，而在官方文檔中，也沒有這方面的引導，這導致我們反覆導入測試多次，問題依然存在，後才考慮可能是機器性能導致的（官方已經在最新的 ansible 安裝腳本中做了硬體的性能檢測），於是申請了幾台高性能機器進行複測，驗證確實是因為機器性能導致。後在與官方人員溝通時得知，整個 TiDB 架構是面向未來、面向海量數據高並發場景，底層存儲技術（如數據定位 seek）都是針對當前主流的 SSD 進行設計和優化的，不會對傳統的 SATA/SAS 機械硬碟再進行優化。至於官方文檔和報錯信息，他們也在持續快速的更新中。

展望

在與官方進行詳細溝通，聽取官方架構師的分享後，我們近期打算再上 2-3 套 TiDB 集群對眾多不同業務線主從 MySQL 進行整理歸納，這樣不但可以逐步統一、規範資料庫的使用，而且還可以大大減少機器資源浪費，運維成本，同時藉助 TiDB 實現我司資料庫的高可用。而在聽取分享的其他部門的小夥伴也已經行動起來，對於我司一個重點 OLTP 新項目，已經確定使用 Cloud TiDB（在 K8S 上部署 TiDB ）作為資料庫系統。同時我們了解到，TiDB 不僅僅滿足 OLTP 業務，它還能滿足很多 OLAP 業務場景，聽完分享後，大數據組小夥伴也在躍躍欲試中。

未來，我們將加強與 PingCAP 官方的溝通交流，進行更深入的研究和開發，持續提升 TiDB 的性能，將它全面應用到鳳凰網業務中。

? 作者：鳳凰網工程師 卞新棟