如何進行中移物聯(lián)網(wǎng)在車聯(lián)網(wǎng)場景的TiDB探索和實現(xiàn)

如何進行中移物聯(lián)網(wǎng)在車聯(lián)網(wǎng)場景的TiDB探索和實現(xiàn)，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

中移物聯(lián)網(wǎng)有限公司是中國移動通信集團公司投資成立的全資子公司，公司按照中國移動整體戰(zhàn)略布局，圍繞“物聯(lián)網(wǎng)業(yè)務(wù)服務(wù)的支撐者、專用模組和芯片的提供者、物聯(lián)網(wǎng)專用產(chǎn)品的推動者”的戰(zhàn)略定位， 專業(yè)化運營物聯(lián)網(wǎng)專用網(wǎng)絡(luò)，設(shè)計生產(chǎn)物聯(lián)網(wǎng)專用模組和芯片，打造車聯(lián)網(wǎng)、智能家居、智能穿戴等特色產(chǎn)品，開發(fā)運營物聯(lián)網(wǎng)連接管理平臺 OneLink 和物聯(lián)網(wǎng)開放平臺 OneNET，推廣物聯(lián)網(wǎng)解決方案，形成了五大方向業(yè)務(wù)布局和物聯(lián)網(wǎng)“云-管-端”全方位的體系架構(gòu)。

下面主要介紹車聯(lián)網(wǎng)業(yè)務(wù)，它主要圍繞車載位置終端和車載視頻終端開展業(yè)務(wù)，包括停車衛(wèi)士、路尚個人、路尚行業(yè)、和統(tǒng)一填裝業(yè)務(wù)。截止 2020 年 5 月，累計接入 150 萬終端，車聯(lián)網(wǎng)用戶主要是個人用戶和企業(yè)用戶，目前累計注冊個人用戶 151 萬，累計注冊企業(yè)用戶 1471 個。

基礎(chǔ) IOV 架構(gòu)

首先講一下基礎(chǔ)架構(gòu)，車載設(shè)備中搭載在小汽車上的 opd 設(shè)備會根據(jù)業(yè)務(wù)類型的配置，及時發(fā)送報文到切入計算模塊和分發(fā)引擎，將報文按照預(yù)先制定的協(xié)議解析，把不同的信息分發(fā)到下游不同的服務(wù)。比如，軌跡服務(wù)、告警服務(wù)。不同服務(wù)的存儲媒介是不一樣的，比如說軌跡放到 TiDB，位置服務(wù)放在 Redis 集群，行車視頻是放在七牛的對象存儲，完整的報文信息是放在 HBase 做數(shù)據(jù)分析。

IOV 核心場景

場景一：設(shè)備管理模塊

設(shè)備管理主要是記錄車載設(shè)備的各種狀態(tài)信息數(shù)據(jù)，部分數(shù)據(jù)更新頻率比較高，峰值達到 1.2 萬字/秒。在用 TiDB 之前設(shè)備管理是放在 Redis Cluster 里面的，放到 TiDB 里面驗證，主要是想看它處理 update 語句的效率。

場景二：行車軌跡

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

行車軌跡存儲演進

2017 年，行車軌跡是跑在 Oracle 的雙機 RAC 上面的，在去 IOE 的浪潮下，業(yè)務(wù)的發(fā)展受到了限制，Oracle 相關(guān)的硬件采購需求得不到集團的批準，因此我們開始考慮把整個行車軌跡的存儲遷移到開源的數(shù)據(jù)庫上面。當時選擇了 MySQL 作為遷移方向，但是軌跡模塊在 Oracle 上面體量比較大，有 8 T 的數(shù)據(jù)，前期 MySQL 肯定是無法承載這樣規(guī)模的業(yè)務(wù)，因此我們當時考慮將數(shù)據(jù)進行水平的切片，結(jié)合 Oracle 的環(huán)境，QPS 峰值大概是 1 萬。當時把分片的數(shù)量定在三個，由代碼控制具體某個設(shè)備的軌跡數(shù)據(jù)，給到具體哪一個分片。在我們驗證的過程中，發(fā)現(xiàn) 3 個節(jié)點處理不了，于是我們擴展到 8 個節(jié)點，這個時候基本上可以承載整個軌跡服務(wù)的數(shù)據(jù)寫入了，但是業(yè)務(wù)側(cè)的邏輯又變得相當?shù)姆敝?，維護的成本非常高，因此想找一個中間件來替代代碼的分片功能。

于是我們選擇了 MyCat，幾經(jīng)調(diào)整過后，由 16 臺 X86 的物理機組成了 8 組 MySQL 的節(jié)點，將 Oracle 替換了下來。過程并不順利，在使用 MyCat 的前期，寫入的性能不好，隊列經(jīng)常積壓，我們想了一些辦法來優(yōu)化，比如在寫數(shù)據(jù)到 MyCat 之前，將每條軌跡進行一致性 hash 的計算，把 hash 值一樣的數(shù)據(jù)歸在一起，然后再批量寫入到 MyCat，來減少把 MyCat 分發(fā)到各個 data note 的開銷。另外還采用了 Twitter 的分布式自增 ID 算法 sonwflake 用于 ID 組件，改造成自增的 Big Int 類型組件，提高寫入性能。

使用 MyCat 一段時間后，我們也在思考，目前的集群如果要做節(jié)點的擴容，成本高不高？風險大不大？結(jié)論是我們要花 4 到 5 天的時間來做節(jié)點擴容后的數(shù)據(jù)遷移，顯然這個成本是相當昂貴的。這個時候，我們關(guān)注到了 TiDB，官方介紹這個產(chǎn)品支持彈性的水平擴展，能夠輕松的應(yīng)對高并發(fā)，海量數(shù)據(jù)場景，支持分布式事務(wù)，并且有自動的災(zāi)難恢復(fù)和故障轉(zhuǎn)移功能，聽上去非常的誘人，我就找研發(fā)大佬聊了這個事情，我們一拍即合，后面的事情進展很順利，資源申請、部署環(huán)境，我們很快的把 3 個 TiDB server、3 個 TiKV 和 3 個 PD 集群布置好，開始了一系列的場景驗證。

遇到的問題

第一個問題是在驗證設(shè)備管理模塊的時候，發(fā)現(xiàn)整個集群每一個節(jié)點的負載其實并不高，但是處理的效率比較低，導(dǎo)致隊列有積壓。為了解決這個問題，我們也咨詢了官方的同事，進行了一些優(yōu)化，比如調(diào)整批量的更新來減少開銷，擴容一個 TiDB 的 server 節(jié)點，最重要的是把 TiDB 版本從 2.04 升級到 3.05。

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

TiDB 解決了哪些痛點問題

第一，它的水平擴展特性解決了 MyCat 等中間件分庫分表帶來的維護成本高的問題。通過無縫擴展 TiDB 和 TiKV 實力，提高系統(tǒng)的計算能力和存儲能力。

第二，TiDB 兼容現(xiàn)有的 MySQL 的語法和協(xié)議，遷移成本低。我們從 MyCat 集群遷移到 TiDB 業(yè)務(wù)代碼都非常少。在數(shù)據(jù)遷移方面，歷史數(shù)據(jù)通過開發(fā)的遷移小工具，從 MyCat 集群讀取出來，然后寫到 TiDB 集群，數(shù)據(jù)是在代碼層做的雙寫，我們很順利的將數(shù)據(jù)遷移到了 TiDB。

第三，海量數(shù)據(jù)下，查詢效率非常優(yōu)秀。我們的軌跡數(shù)據(jù)是按照日期分區(qū)的，每天會寫入 4 億到 5 億的數(shù)據(jù)，那么在這個量級的數(shù)據(jù)場景下，我們設(shè)備 ID 的查詢一般在 10 毫秒就能夠返回結(jié)果，能夠滿足我們業(yè)務(wù)場景的需求。 第四，擴容和升級非?？旖荨iDB 在版本升級方面真的非常好用，把準備工作做好之后，3、4 分鐘不到就完成了整個升級，用戶體驗非常棒。

TiDB 在物聯(lián)網(wǎng)的應(yīng)用前景

我們公司的核心產(chǎn)品是物聯(lián)卡，目前卡片數(shù)量在 7 億以上；另外一個產(chǎn)品是智能組網(wǎng)，現(xiàn)在有將近 1600 萬的家庭網(wǎng)關(guān)；在智能家居和智能娛樂方面，我們有 700 萬左右的攝像頭和智能穿戴設(shè)備，這幾個場景都是屬于高并發(fā)以及海量數(shù)據(jù)的場景，我認為這些場景都是比較適合遷移到 TiDB 上面跑的。隨著我們車聯(lián)網(wǎng)場景在 TiDB 上的使用越來越成熟，未來我們會推動更多的業(yè)務(wù)，遷移到 TiDB 上面。同時，也希望 PingCAP 公司的同學(xué)們，能夠給我們帶來更優(yōu)秀的產(chǎn)品。

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