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

10年積累的網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有綠園免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

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

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

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

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

IOV 核心場(chǎng)景

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

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

場(chǎng)景二：行車軌跡

行車軌跡場(chǎng)景主要是行車軌跡數(shù)據(jù)的寫(xiě)入和少量軌跡查詢的請(qǐng)求，日均寫(xiě)入量在 4.5 億行數(shù)據(jù)。目前驗(yàn)證集群的規(guī)模數(shù)據(jù)在 300 億行左右，最終規(guī)模會(huì)達(dá)到 1600 億行以上，那時(shí)就算是一個(gè)比較海量的數(shù)據(jù)了。

行車軌跡存儲(chǔ)演進(jìn)

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

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

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

遇到的問(wèn)題

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

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

TiDB 解決了哪些痛點(diǎn)問(wèn)題

第一，它的水平擴(kuò)展特性解決了 MyCat 等中間件分庫(kù)分表帶來(lái)的維護(hù)成本高的問(wèn)題。通過(guò)無(wú)縫擴(kuò)展 TiDB 和 TiKV 實(shí)力，提高系統(tǒng)的計(jì)算能力和存儲(chǔ)能力。

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

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

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

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

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