中移物联网在车联网场景的 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 亿行以上，那时就算是一个比较海量的数据了。
行车轨迹存储演进

文章插图
【中移物联网在车联网场景的 TiDB 探索和实现】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 类型组件，提高写入性能。