作者简介：薛超，中移物联网有限公司数据库运维高级工程师
中移物联网有限公司是中国移动通信集团公司投资成立的全资子公司，公司依照中国移动整体策略布局，围绕“物联网业务服务的撑持者、专用模组和芯片的提供者、物联网专用产品的推动者”的策略定位，专业化经营物联网专用网络，设计生产物联网专用模组和芯片，打造车联网、智能家居、智能穿戴等特色产品，开发经营物联网连贯治理平台 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 公司的同学们，可能给咱们带来更优良的产品。