TiDB 助力牛板金互聯網金融營銷平台

公司介紹

「牛板金」是浙江佐助金融信息服務有限公司旗下綜合性互聯網理財服務平台，總部位於杭州。牛板金致力於為投資者提供安全、專業、便捷、高效的創新性互聯網理財服務，降低投資者的投資門檻，多渠道增加居民財產性收入；支持中小微企業發展，助力實體經濟，實現真正意義的「普惠金融」。

截至目前，牛板金已有註冊用戶接近 80 萬人，累計投資金額超過 200 億元。

TiDB 在牛板金的主要應用場景

場景 1：營銷系統

在牛板金中，我們的用戶最喜歡的一件事就是打開 App，然後進行簽到獲取積分，再拿積分兌換加息券來獲得更多的收益。正因為此，在整個牛板金營銷平台的後台資料庫中負責記錄用戶積分信息的表（積分流水表）增長的比我們想像的要快很多，不到一年就已經超過 5000 萬，而且增速越來越快，不得不開始對其開始優化。

上線 MyCAT

一開始我們我們調研了很多相關的資料庫分散式中間件產品，包括 TDDL、Cobar、MyCAT、Sharding-JDBC。當時通過一定的考量後，我們選用了 MyCAT 作為分庫分表方案，按照時間維度對錶進行了拆分。然而實際線上運行過程中，還是遇到了很多問題，大致有以下幾種：

• MyCAT 運行不夠穩定且高可用機制欠佳，有兩次比較嚴重的宕機導致我們線上服務的部分不可用；
• 主鍵衝突，採用 MySQL 單表的自增主鍵，導致多表掃描合併結果集再排序出現不同順序的情況；
• 自增主鍵，由於採用了 MyCAT 的自增主鍵方式，導致線上線下必須全部採用 MyCAT 環境，增加了運維複雜度；
• 按月度分表，沒有解決單表熱點問題，現在單表又已經突破千萬，存在需要再次修改分庫分表策略的問題；
• 另外考慮到 MyCAT 的集群擴容機制不夠完善，擴容操作比較困難且會對業務可用性產生影響。

對比 TiDB vs MyCAT

因此我們決定尋找是否有更優的解決方案，能夠一勞永逸的解決這個問題，這時候 TiDB 再次進入我們的視野，當時 TiDB 剛剛發布了 RC4 版本。在經過一輪詳細的測試後，我們發現 TiDB 在數據量不斷增長後優勢還是很明顯的，不管對比單機 MySQL 還是 MyCAT，主要優勢有以下幾點：

• 高度兼容 MySQL 協議，數據分散式存取模式對業務開發透明，開發人員無需過多關注其本身；
• 彈性擴容，使用官方 TiDB-Ansible 工具可在線對相應節點進行擴容；
• OLTP，滿足數據強一致性需求；
• 技術支持，PingCAP 的技術支持團隊響應很快，能夠第一時間解答我們的問題。

我們開始測試 TiDB，並與 MySQL + MyCAT 傳統分庫分表中間件方式做了調研比較。

下面是我們調研比較後一些結論和心得：

• TiDB 不需要像 MySQL + MyCAT 關心後台數據分片規則設計和存儲，對於業務開發工作量和工作難度的降低有很大的幫助。業務代碼的靈活性和可維護性也大幅提高了。
• TiDB 的性能提升基本是線性的，橫向擴展能力比較強；受制於 MyCAT 自身的性能限制，MySQL + MyCAT 的性能無法做到線性提升，這點對我們高速增長的業務發展趨勢來說是特別看重的。
• MySQL + MyCAT 的高可用雖然可以通過一些第三方組件和配置完成，但是總體的可靠性可用性不能滿足我們金融企業的安全要求；TiDB 是一個沒有單點的高可用架構，已經具備了完整的高可用保障機制，無需我們耗費額外的精力去規劃和考慮。
• 我們對 TiDB 和 MySQL + MyCAT 的性能也做了評測，在大數據量（千萬到億單表記錄數）的規模下，TiDB 幾乎不需要太多的配置優化就能很好的完成數據處理，MySQL + MyCAT 則需要人為調整一堆參數，反覆調試；性能上 TiDB 有不俗的表現，我們經過測試，在多表和上述單表大規模數據量規模下，TiDB（當時測試的是 RC4 版本） 相比 MySQL + MyCAT 在性能上至少有 1.5 倍到 2 倍的優勢，如果進一步優化的話，兩者的差距還有可能更大。
• 我們還關注了性能壓力測試過程中的穩定性表現。TiDB 的吞吐量和延遲指標的變化隨負載請求壓力增加變化穩定，MySQL + MyCAT 的性能波動比較大，這個結果對我們的金融業務是否能夠穩定在線開展服務非常重要。

上線 TiDB

在我們決定遷移 TiDB 後，一個最大的問題就來了，如何在保證數據一致性的前提下更快的將數據遷移同步到 TiDB 集群，這時候我們聯繫了 PingCAP 官方，他們給我們提供了一個很好的解決方案。

最終我們採用的同步方案是 Loader + Syncer，具體方案如下：

• 使用 Mydumper + TiDB Loader 全量導出 MySQL 庫中數據，並記錄 SavePoint，然後導入 TiDB。
• 使用 TiDB Syncer 做實時增量同步，將 MySQL 中數據同步到 TiDB。
• 將 MyCAT 中按月拆分的表通過 ETL 以無主鍵的形式導回 MySQL 單表（ MyCAT 分表中存在主鍵重複，不能單純直接導入 TiDB，並且當時 TiDB 對於 ETL 工具的支持還未完善，無法使用 ETL工具導入 TiDB），只保留當前月份數據不導入。
• 將重新整合後的 MySQL 單表數據通過 Mydumper + TiDB Loader 導入 TiDB。
• 待上線當天晚上，將當前月份數據導回 MySQL（重建主鍵），再通過 Mydumper + TiDB Loader 導入TiDB。

這個方案雖然複雜但能將遷移的時間縮減到最短。

在測試的過程中我們發現，TiDB 在進行一些複雜的強 OLAP 查詢時會導致整個集群處於 busy 狀態，進而影響到 OLTP 業務，通過和 PingCAP 技術團隊溝通，TiDB 官方的建議是，對於一個集群存在混合業務的場景：

• 對於不同類型的業務，可以通過不同的 TiDB-Server 作為入口，在計算層面做隔離；
• 另外不同的業務可以通過不同的隔離級別（比如 OLAP 業務使用 RC 隔離級別）、設置語句優先順序（OLAP 請求設置為低優先順序）以及控制執行並發度等方式進行資源使用優化。

我們最後決定採用主從集群模式，通過搭建一組 TiDB 從集群，採用 TiDB Binlog 對主從集群進行同步，這樣 Master 集群負責 OLTP 業務，而 Slave 集群負責 OLAP 業務，兩者之間就沒有相互影響，而且通過實測，TiDB Binlog 的同步延遲大概在秒級，對於我們的 OLTP 業務沒有影響。兩套集群的配置大致一樣，Slave 集群只比 Master 集群少一台 TiDB 角色。

最終，完成生產上的 TiDB 主從兩套集群的部署和投產。架構如下：

資料庫集群總體配置如下：2*TiDB、3*TiKV、3*PD。

到目前為止，TiDB 穩定運行近半年，隨著牛板金業務規模的逐漸放量，資料庫數據處理能力穩定提升。

場景 2：流量採集系統

該系統主要是對我們系統的所有請求流量進行存儲以便後期進行分析。由於數據量將會非常大，因此從一開始我們就規劃使用 TiDB，這樣就可以使用傳統的 SQL 來進行分析查詢。我們還了解到 PingCAP 的另一個項目 TiSpark，也是很適合在我們這個場景使用，下一步就是規劃部署 TiSpark 集群。

對於請求的採集形式，我們是採用在網關層增加一個 Filter 的形式，將請求的相關參數進行採集然後通過消息隊列將 message 發送到 MQ，然後通過請求分析處理系統從 MQ 中拉取消息，最後落庫。現在只對 App 端的流量做了處理，每天的數據量大約在 1000 萬左右。

對於這些數據的分析，大致計劃有以下幾方面：

• 訪問情況的統計報表；
• 安全分析，構建安全防範策略；
• 全鏈路壓力測試，這些是天然的請求源數據。

通過 TiDB 的在混合負載方面的能力，可以接受海量採集數據的不斷寫入，同時能夠實時的提供分析、統計及計算。在運維方面也不用擔心快速膨脹的數據對容量管理和擴容操作帶來的繁瑣和麻煩。TiDB 提供的 ansible 方式的管理可以提供方面的一鍵擴容操作。目前我們計劃在 2018 年春節後上線該項目。

問題和建議

實踐中我們認識到，由於 TiDB 是一個分散式資料庫，不可避免的會有網路開銷，尤其是對於小表，這個影響會被成倍放大，如果 TiDB 能夠對小數據量的表進行特殊優化，讓其性能能夠接近單機資料庫，那對於 TiDB 的使用場景可能會更多，畢竟一個系統中的表不只是擁有海量數據的表，而且也不一定能夠採用多數據源的方式來進行修改調整。

2018 開年後，和 TiDB 開發團隊溝通此問題，他們表示正在著手解決這個問題，目前在嘗試通過 TiKV 端引入 Query Cache 來加速頻繁查詢，對小表以及聚合類查詢的響應速度會有很好的提升，對此我們非常期待。

? 作者介紹：沈晨波 佐助金融 資深架構師