中移物联网有限公司是中国移动通信集团公司投资成立的全资子公司，公司依照中国移动整体策略规划，围绕“物联网业务供职的撑持者、专用模组和芯片的提供者、物联网专用产品的推动者”的策略定位， 专业化运营物联网专用网络，设计出产物联网专用模组和芯片，打造车联网、智能家居、智能穿戴等特色产品，开发运营物联网连接解决平台 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 集群放置好，开始了一系列的场景验证。

遇到的问题