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

如何進行中移物聯網在車聯網場景的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 公司的同學們，能夠給我們帶來更優秀的產品。

關于如何進行中移物聯網在車聯網場景的TiDB探索和實現問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。