中移物聯網在車聯網場景的 TiDB 探索和實現

作者簡介：薛超，中移物聯網有限公司資料庫運維高階工程師

中移物聯網有限公司是中國行動通訊集團公司投資成立的全資子公司，公司按照中國移動整體戰略佈局，圍繞 “物聯網業務服務的支撐者、專用模組和晶片的提供者、物聯網專用產品的推動者” 的戰略定位， 專業化運營物聯網專用網路，設計生產物聯網專用模組和晶片，打造車聯網、智慧家居、智慧穿戴等特色產品，開發運營物聯網連線管理平臺 OneLink 和物聯網開放平臺 OneNET，推廣物聯網解決方案，形成了五大方向業務佈局和物聯網 “雲-管-端” 全方位的體系架構。

本次分享主要介紹車聯網業務，它主要圍繞車載位置終端和車載視訊終端開展業務，包括停車衛士、路尚個人、路尚行業、和統一填裝業務。截止 2020 年 5 月，累計接入 150 萬終端，車聯網使用者主要是個人使用者和企業使用者，目前累計註冊個人使用者 151 萬，累計註冊企業使用者 1471 個。

基礎 IOV 架構

首先講一下基礎架構，車載裝置中搭載在小汽車上的 opd 裝置會根據業務型別的配置，及時傳送報文到切入計算模組和分發引擎，將報文按照預先制定的協議解析，把不同的資訊分發到下游不同的服務。比如，軌跡服務、告警服務。不同服務的儲存媒介是不一樣的，比如說軌跡放到 TiDB，位置服務放在 Redis 叢集，行車視訊是放在七牛的物件儲存，完整的報文資訊是放在 HBase 做資料分析。

IOV 核心場景

場景一：裝置管理模組

裝置管理主要是記錄車載裝置的各種狀態資訊資料，部分資料更新頻率比較高，峰值達到 1.2 萬字/秒。在用 TiDB 之前裝置管理是放在 Redis Cluster 裡面的，放到 TiDB 裡面驗證，主要是想看它處理 update 語句的效率。

場景二：行車軌跡

行車軌跡場景主要是行車軌跡資料的寫入和少量軌跡查詢的請求，日均寫入量在 4.5 億行資料。目前驗證叢集的規模資料在 300 億行左右，最終規模會達到 1600 億行以上，那時就算是一個比較海量的資料了。

行車軌跡儲存演進

2017 年，行車軌跡是跑在 Oracle 的雙機 RAC 上面的，在去 IOE 的浪潮下，業務的發展受到了限制，Oracle 相關的硬體採購需求得不到集團的批准，因此我們開始考慮把整個行車軌跡的儲存遷移到開源的資料庫上面。當時選擇了 MySQL 作為遷移方向，但是軌跡模組在 Oracle 上面體量比較大，有 8 T 的資料，前期 MySQL 肯定是無法承載這樣規模的業務，因此我們當時考慮將資料進行水平的切片，結合 Oracle 的環境，QPS 峰值大概是 1 萬。當時把分片的數量定在三個，由程式碼控制具體某個裝置的軌跡資料，給到具體哪一個分片。在我們驗證的過程中，發現 3 個節點處理不了，於是我們擴充套件到 8 個節點，這個時候基本上可以承載整個軌跡服務的資料寫入了，但是業務側的邏輯又變得相當的繁重，維護的成本非常高，因此想找一箇中介軟體來替代程式碼的分片功能。

於是我們選擇了 MyCat，幾經調整過後，由 16 臺 X86 的物理機組成了 8 組 MySQL 的節點，將 Oracle 替換了下來。過程並不順利，在使用 MyCat 的前期，寫入的效能不好，佇列經常積壓，我們想了一些辦法來優化，比如在寫資料到 MyCat 之前，將每條軌跡進行一致性 hash 的計算，把 hash 值一樣的資料歸在一起，然後再批量寫入到 MyCat，來減少把 MyCat 分發到各個 data note 的開銷。另外還採用了 Twitter 的分散式自增 ID 演算法 sonwflake 用於 ID 元件，改造成自增的 Big Int 型別元件，提高寫入效能。

使用 MyCat 一段時間後，我們也在思考，目前的叢集如果要做節點的擴容，成本高不高？風險大不大？結論是我們要花 4 到 5 天的時間來做節點擴容後的資料遷移，顯然這個成本是相當昂貴的。這個時候，我們關注到了 TiDB，官方介紹這個產品支援彈性的水平擴充套件，能夠輕鬆的應對高併發，海量資料場景，支援分散式事務，並且有自動的災難恢復和故障轉移功能，聽上去非常的誘人，我就找研發大佬聊了這個事情，我們一拍即合，後面的事情進展很順利，資源申請、部署環境，我們很快的把 3 個 TiDB server、3 個 TiKV 和 3 個 PD 叢集佈置好，開始了一系列的場景驗證。

遇到的問題

第一個問題是在驗證裝置管理模組的時候，發現整個叢集每一個節點的負載其實並不高，但是處理的效率比較低，導致佇列有積壓。為了解決這個問題，我們也諮詢了官方的同事，進行了一些優化，比如調整批量的更新來減少開銷，擴容一個 TiDB 的 server 節點，最重要的是把 TiDB 版本從 2.04 升級到 3.05。

另外一個問題就是熱點資料，因為 MySQL 的模型元件用的是自增的 int 型別，遷移過來以後熱點資料效應比較明顯。為了解決這一問題，我們將主鍵改成 uuid，通過 shard_row_id_bits=N 這樣的語句，來將資料打散，打散後資料寫入的效率大大提升。聽說現在 4.0 GA 版本的 AutoRandom 可以解決同樣的問題，不再需要使用 uuid 作為元件，我們可以期待一下這個版本的新特性。

TiDB 解決了哪些痛點問題

第一，它的水平擴充套件特性解決了 MyCat 等中介軟體分庫分錶帶來的維護成本高的問題。通過無縫擴充套件 TiDB 和 TiKV 實力，提高系統的計算能力和儲存能力。

第二，TiDB 相容現有的 MySQL 的語法和協議，遷移成本低。我們從 MyCat 叢集遷移到 TiDB 業務程式碼都非常少。在資料遷移方面，歷史資料通過開發的遷移小工具，從 MyCat 叢集讀取出來，然後寫到 TiDB 叢集，資料是在程式碼層做的雙寫，我們很順利的將資料遷移到了 TiDB。

第三，海量資料下，查詢效率非常優秀。我們的軌跡資料是按照日期分割槽的，每天會寫入 4 億到 5 億的資料，那麼在這個量級的資料場景下，我們裝置 ID 的查詢一般在 10 毫秒就能夠返回結果，能夠滿足我們業務場景的需求。 第四，擴容和升級非常快捷。TiDB 在版本升級方面真的非常好用，把準備工作做好之後，3、4 分鐘不到就完成了整個升級，使用者體驗非常棒。

TiDB 在物聯網的應用前景

我們公司的核心產品是物聯卡，目前卡片數量在 7 億以上；另外一個產品是智慧組網，現在有將近 1600 萬的家庭閘道器；在智慧家居和智慧娛樂方面，我們有 700 萬左右的攝像頭和智慧穿戴裝置，這幾個場景都是屬於高併發以及海量資料的場景，我認為這些場景都是比較適合遷移到 TiDB 上面跑的。隨著我們車聯網場景在 TiDB 上的使用越來越成熟，未來我們會推動更多的業務，遷移到 TiDB 上面。同時，也希望 PingCAP 公司的同學們，能夠給我們帶來更優秀的產品。