TiDB 在摩拜單車在線數據業務的應用和實踐

做者：Mobike / 技術研發部 / 基礎平臺中心 丁宬傑 胡明

背景

摩拜單車於 2015 年 1 月成立，2016 年 4 月 22 日地球日當天正式推出智能共享單車服務，截至 2017 年 11 月中旬，已前後進入國內外超過 180 個城市，運營着超過 700 萬輛摩拜單車，爲全球超過 2 億用戶提供着智能出行服務，日訂單量超過 3000 萬，成爲全球最大的智能共享單車運營平臺和移動物聯網平臺。摩拜天天產生的騎行數據超過 30TB，在全球擁有最爲全面的騎行大數據，飛速增加的業務使摩拜面臨數據庫擴展與運維的巨大挑戰。

面對飛速增加的併發數與數據量，單機數據庫終將因沒法支撐業務壓力而罷工。在摩拜正式上線以來，咱們就在不斷思考數據庫擴展和運維的將來，近年來業內對數據庫進行擴展的常見的方案是經過中間件把數據庫表進行水平拆分，將表內數據按照規則拆分到多個物理數據庫中。使用這樣的中間件方案，在數據庫擴容時須要先停下業務，再重構代碼，以後進行數據遷移，對於摩拜這樣與時間賽跑的創業公司來說代價巨大，中間件方案對業務過強的侵入性，不支持跨分片的分佈式事務，沒法保證強一致性事務的特性都使咱們望而卻步。

摩拜單車於 2017 年初開始使用 TiDB，從最先的 RC三、RC四、PreGA、到如今的 1.0 正式版，一步步見證了 TiDB 的成熟和穩定。目前支撐着摩拜內部的實時分析和部分線上業務，同時正在規劃遷移更多的線上業務至 TiDB。

目前，TiDB 在摩拜部署了數套集羣，近百個節點，承載着數十 TB 的各種數據。

TiDB 在摩拜的角色和主要應用場景

在摩拜，TiDB 是一個核心的數據交易與存儲支撐平臺，引入它的主要目的是用來解決海量數據的在線存儲、大規模實時數據分析和處理。

在咱們看來，TiDB 的好處主要有：

• 彈性擴容。具備 NoSQL 相似的擴容能力，在數據量和訪問流量持續增加的狀況下可以經過水平擴容提升系統的業務支撐能力，而且響應延遲穩定；
• 簡單易用。兼容 MySQL 協議，基本上開箱即用，徹底不用擔憂傳統分庫分表方案帶來的心智負擔和複雜的維護成本，並且用戶界面友好，常規的技術技術人員均可以很高地進行維護和管理；
• 響應及時。由於和 PingCAP 團隊有很是深刻的合做關係，因此有任何問題均可以第一時間和 PingCAP 團隊直接溝通交流，遇到問題都能很快的處理和解決。

下面介紹 TiDB 的應用場景：

場景一：開關鎖日誌成功率統計

開關鎖成功率是摩拜業務監控的重點指標之一。

在每次開、關鎖過程當中，用戶和鎖信息會在關鍵業務節點產生海量日誌，經過對線上日誌的彙總分析，咱們把用戶的行爲規整爲人和車兩個維度，經過分佈式、持久化消息隊列，導入並存放到 TiDB 裏。在此過程當中，經過對不一樣的實體添加不一樣的標籤，咱們就能方便地按照地域、應用版本、終端類型、用戶、自行車等不一樣的維度，分別統計各個類別的開鎖成功率。

按照咱們的估計，這個業務一年的量在數百億，因此使用單機的 MySQL 庫須要頻繁的進行歸檔，特別是遇到單機數據庫瓶頸的狀況下，擴容更是帶來了很是大的挑戰，這在咱們有限的人力狀況下，徹底是個災難。因此要支撐整個 Mobike 的後端數據庫，咱們必需要尋找簡單易用的方案，極大地減小在單個業務上的人力成本開銷。其次，根據咱們以前使用分庫分表的經驗，對於這類須要頻繁更新表結構進行 DDL 操做的業務，一旦數據量過大，很很容易出現數據庫假死的狀況，不只影響服務的可用性，更嚴重的是極可能致使數據不一致的狀況出現。最後，咱們但願無論從此的業務量如何激增，業務需求如何變化，均可以保持業務邏輯能夠很方便地升級支持。

在方案設計時，咱們進行考察了 MySQL 分庫分表的方案和 TiDB 方案的對比。

咱們先估計了可能的狀況：

• 新業務上線，在線變更確定是常常發生的；
• 儘量存長時間的數據，以備進行統計比較；
• 數據要支持常常性的關聯查詢，支撐運營組的臨時需求；
• 要能支撐業務的快速增加或者一些特殊活動形成的臨時流量。

考慮到這些狀況，MySQL 分庫分表的方案就出現了一些問題，首先頻繁變更表結構就比較麻煩，而 TiDB 能夠進行在線 DDL。數據生命期比較長，能夠設計之初作一個比較大的集羣，可是彈性就比較差，針對這個問題，TiDB 能夠根據須要，彈性的增長或者減小節點，這樣的靈活性是 MySQL 分庫分表沒有的。另外，數據要支持頻繁的複雜關聯查詢，MySQL 分庫分表方案徹底沒辦法作到這一點，，而這偏偏是 TiDB 的優點，經過以上的對比分析，咱們選擇了 TiDB 做爲開關鎖日誌成功率統計項目的支撐數據庫。

目前，大體能夠將到端到端的延時控制在分鐘級，即，如有開鎖成功率降低，監控端可即時感知，此外，還能經過後臺按用戶和車查詢單次故障騎行事件，幫助運維人員快速定位出故障的具體位置。

場景二：實時數據分析

數據分析場景中，TiDB 能夠從線上全部的 MySQL 實例中實時同步各種數據，經過 TiDB 周邊工具 Syncer 導入到 TiDB 進行存儲。

這個業務的需求很簡單，咱們線上有數十個 MySQL 集羣，有的是分庫分表的，有的是獨立的實例。這些孤立的數據要進行歸集以便供業務方進行數據分析。咱們一開始計劃把這些庫同步到 Hive 中，考察了兩種方式，一種是每日全量同步，這麼作，對線上的庫壓力以及 Hive 的資源開銷都會愈來愈大。另外一種是增量同步，這種方式很是複雜，由於 HDFS 不支持 update，須要把每日增量的部分和以前的部分作 merge 計算，這種方法的優勢是在數據量比較大的狀況下，增量同步對比全量同步要更快、更節省空間，缺點是佔用至關一部分Hadoop 平臺的計算資源，影響系統穩定性。

TiDB 自己有不少不錯的工具，能夠和 MySQL 的生態方便的鏈接到一塊兒。這裏咱們主要使用了 TiDB 的 syncer 工具，這個工具能夠方便的把 MySQL 實例或者 MySQL 分庫分表的集羣都同步到 TiDB 集羣。由於 TiDB 自己能夠 update，因此不存在 Hive 裏的那些問題。同時有 TiSpark 項目，數據進入 TiDB 之後，能夠直接經過 Spark 進行很是複雜的 OLAP 查詢。有了這套系統，運營部門提出的一些複雜在線需求，都可以快速簡潔的完成交付，這些在 Hadoop 平臺上是沒法提供這樣的實時性的。

目前，該集羣擁有數十個節點，存儲容量數十 T，受益於 TiDB 自然的高可用構架，該系統運行穩定，往後集羣規模日益變大也僅需簡單增長 x86 服務器便可擴展。後臺開發、運維、業務方等均可以利用 TiDB 的數據聚合能力彙總數據，進行數據的彙總和分析。

場景三：實時在線 OLTP 業務

如前所述，對比傳統的分庫分表方案，TiDB 的靈活性和可擴展性在實時在線業務上優點更加明顯。

根據咱們的測試，TiDB 在數據量超過 5 千萬時，對比 MySQL 優點較大，同時協議層高度兼容 MySQL，幾乎不用修改業務代碼就能直接使用，因此 TiDB 集羣對於數據量大的實時在線業務很是適合。

目前，摩拜主要上線了兩套在線 OLTP 業務，分別是摩豆信用分業務和摩豆商城業務。

摩豆信用分業務

摩拜單車信用分業務與用戶騎行相關，用戶掃碼開鎖時先行查詢用戶信用積分判斷是否符合騎行條件，待騎行完成後，系統會根據用戶行爲進行信用分評估並進行修改。當單車沒法騎行，上報故障覈實有效後增長信用分、舉報違停覈實有效後下降信用分；可是若是不遵照使用規範，則會扣除相應的信用分；例如用戶將自行車停在禁停區域內，系統就會扣除該用戶的部分信用分做爲懲罰，並存檔該違停記錄。當用戶的信用分低於 80 分時，騎行費用將會大幅上升。

摩豆商城業務（APP 中的摩拜成就館）

魔豆商城業務即摩拜成就館，用戶的每一次騎行結束後，系統會根據騎行信息贈送數量不等的省時幣、環保幣、健康幣做爲積分，經過積累這些積分能夠在摩拜成就館內兌換相應積分的實物禮品。

這些業務的共同特色：

• 724365 在線，須要系統很是健壯，在任何情況下保證穩定運行；
• 數據不但願刪除，但願能一直保存全量數據；
• 平時高峯期併發就很是大，搞活動的時候併發會有幾倍的增加；
• 即使有業務變動，業務也不能暫停。

因爲是典型 OLTP 場景，可選項並很少，並且數據量增加極快，這些數據庫的數據在一年內輕鬆達到數百億量級。這些場景在咱們有了 TiDB 的使用經驗之後，發現 TiDB 的全部特性都很是契合這種海量高併發的 OLTP 場景。TiDB 的容量/併發可隨意擴展的特性不在贅述，支持在線 DDL 這個特性特別適合這些業務，有須要業務更改不會阻塞業務，這是咱們業務快速迭代比較須要的特性。

目前，這兩個在線 OLTP 集羣擁有數十個節點，百億級數據，上線之後很是穩定，PingCAP 客戶支持團隊也協助咱們進行該集羣的平常運維工做。

場景四：違章停車記錄/開鎖短信庫等日誌歸集庫

相對於傳統的針對不一樣的業務分別部署 MySQL 集羣的方案，TiDB 在可擴展性和在線跨庫分析方面有較大優點。

在部署 TiDB 以前，摩拜面對新增的業務須要對其進行單獨的規劃和設計，並根據業務的數據量，增速以及併發量設計 MySQL 的分庫分表方案，這些重複的預先設計工做在所不免。另外一方面，不一樣業務之間每每是有關聯的，當運營部門須要不一樣業務的彙總數據時，就變得異常麻煩，須要新建一個臨時的數據彙總中心，例如新建一套 MySQL 分庫分表的集羣，或者臨時向大數據組申請 Hive 的空間，這都讓數據提供的工做變得麻煩。

有了 TiDB 之後，此類業務的開發和數據提供都變得很是簡單，每次新需求下來，只須要按照新增數據量增長 TiKV 節點的數量便可，由於整個集羣變得比較大，併發承載能力很是強，基本不須要考慮併發承載能力。特別的好處是，由於這些業務有相關性的業務，放在一個獨立的數據庫中，運營須要提供某幾類某段時間的數據時就變得極爲方便。

基於 TiSpark 項目，Spark 集羣能夠直接讀取 TiDB 集羣的數據，在一些運營須要實時數據提供的場景，再也不須要按照原有的提供數據到大數據平臺，設計 ETL 方案，運營再去大數據部門溝通運算邏輯。而是直接在 TiDB 現有數據的基礎上，直接提出複雜的分析需求，設計 Spark 程序進行在線的直接分析便可。這樣作，咱們很是容易就能夠實現一些實時狀態的分析需求，讓數據除了完成本身的工做，還能更好的輔助運營團隊。

使用過程當中遇到的問題和優化

在說優化問題以前，先看 TiDB 的架構圖，整個系統大體分爲幾個部分。

其中：

• PD 是整個集羣的管理模塊，負責：元信息管理、集羣調度和分配全局遞增非連續ID。
• TiDB，是客戶端接入層，負責 SQL 解析、執行計劃優化，經過 PD 定位存儲計算所需數據的 TiKV 地址。
• TiKV，是數據的存儲層，底層是基於 RocksDB 的KV引擎，並在其上分別封裝 MVCC 和 Raft 協議，保證數據的安全、一致。
• TiSpark，是 Spark 接入層，負責把 Spark 和 TiKV 鏈接到一塊兒，在執行很是重的 OLAP 業務時能夠利用到 Spark 集羣的優點。

在使用過程當中，遇到過很多問題，可是在我方和 PingCAP 技術團隊的充分交流和協做下，都獲得了比較完善的解決，下面挑選最爲重要的資源隔離與優化展開。

TiKV 中數據存儲的基本單位是 Region，每一個 Region 都會按順序存儲一部分信息。當一個 Region 包含多個表的數據，或一臺機器上有多個 Region 同時爲熱點數據時，就容易產生資源瓶頸。

PD 在設計之初考慮了這方面的問題（專門設計了 HotRegionBalance），可是，它的調度粒度是單個 Region，而且，整個調度基於這樣的假設：即每一個 Region 的資源消耗對等，不一樣 Region 之間沒有關聯，同時儘可能保持 Region 均攤在全部 Store。

但當一個集羣同時承載多個庫，或一個庫中包含多個表時，發生資源瓶頸的機率會明顯提高。

針對這個問題，咱們和 PingCAP 技術團隊合做，對 TiDB 作了如下優化。

優化一：基於 Table 的分裂

這個修改的目的是解決小表數據的相互影響的問題。

當有新表數據插入某一 Region 時，TiKV 會根據當前 Region 的 Key Range 計算出 tableID，若是發現插入的 Key 不在這個 KeyRange 中，會對這個 Region 提早分裂，這就保證了每一個 Region 只包含一個表的數據。

優化二：表級別的資源隔離

與此同時，咱們在 PD 增長了 TableID 和 Namespace 之間的映射關係以及 NameSpace 和 TiKV Store 的映射關係，經過把上述關係持久化到 eEtcd 裏，保證該映射關係的安全。

當數據插入時，能夠在 TiDB 層面拿到 TableID，進而從 PD 找出目標 Region 所在的 TiKV，保證新插入的數據不會放到其餘 TiKV。

另外，咱們還與 PingCAP 團隊共同開發實現了一個 NameSpace 調度器，把未規整的 Region 調度回它應在的 TiKV 裏，進而在表級別保證數據不會相互干擾。

優化三：管理工具

最後的問題是管理 NameSpace 的問題。

好在 TiDB 在早期設計時保留了足夠的靈活性，經過 TiDB 原有接口，咱們只須要調用相關 API 即能經過表名拿到 TableID。

同時咱們在 PD 的命令行管理臺 pc-ctl 中增長了 HTTP 接口，管理確認 Table Name 和 Table ID 之間的對應關係。

後記

部署 TiDB 近一年來，摩拜單車經歷了用戶數量近十倍，日騎行數據數十倍的增加，依靠 TiDB 在線擴容的能力，咱們完成了屢次數據庫擴容與服務器更換，並且這些操做對業務是徹底透明的，咱們能夠更專一於業務程序的開發與優化，而無須瞭解數據庫的分片規則，對於快速成長的初創公司，這有着很強的借鑑意義。另外深度參與 TiDB 的開發並和開源社區緊密的互動，也使咱們得到了不少有益的反饋，極大下降了代碼維護成本。

將來，咱們會聯合 PingCAP 進一步豐富多集羣的管理工具，進行更深刻的研究和開發，持續提高 TiDB 的性能，將 TiDB 應用到更多的業務中。