本文来自涂鸦智能的刘筠松在 PingCAP DevCon 2021 上的分享，包含 TiDB 在 IoT 畛域，特地是在智能家居行业的应用。
对于涂鸦智能
涂鸦智能是一个全球化 IoT 开发平台，打造互联互通的开发规范，连贯品牌、OEM 厂商、开发者、零售商和各行业的智能化需要。基于寰球私有云，实现智慧场景和智能设施的互联互通。涵盖硬件开发工具、寰球私有云、智慧商业平台开发三方面；提供从技术到营销渠道的全面赋能，打造中立且凋谢的开发者生态。
目前涂鸦在国内外曾经有超过十万家的合作伙伴，在 IoT PaaS 和 IoT 的开发者平台的生态客户数量曾经达到 32 万 +，其波及到制造业、零售业、运营商、地产、养老、酒店（PaaS）等。涂鸦赋能的有欧美品牌和中国品牌，包含飞利浦，国内的海尔以及三大运营商。
海量数据的实时响应：TiKV 选型历程
涂鸦的设施在寰球每天解决 840 亿申请，均匀解决顶峰次数能达到 150 万 TPS，均匀响应工夫要求小于 10 毫秒。因为涂鸦是物联网行业，区别于传统行业，没有低峰点，写入量十分大，涂鸦用六年的工夫一直选型尝试，摸索最合适的数据架构。
涂鸦之所以有这么大量的数据，是因为目前人们家里应该都会应用到智能设施，例如智能电灯、扫地机器人，设施联网后就与涂鸦平台有了通信的能力，而智能设施的各种定时触发，比方家里的摄像头巡更、扫地机器人的地位信息都须要上报给涂鸦的 Zeus 平台。Zeus 零碎作为涂鸦平台最重要的角色，负责解决数据上报，业务拓扑如下图所示，利用网关收集到智能设施上报的 MQTT 音讯之后会发送到 Kafka 和 NSQ 下面，Zeus 零碎会生产这些音讯进行解密，解决过后要放到存储外面。本文次要形容的也正是从 Zeus 到存储之间的这段产品选型。
AWS Aurora
涂鸦在晚期应用的是 AWS Aurora。Aurora 跟阿里云的 PolarDB 相似，是存算拆散的架构，涂鸦在 Aurora 上稳固运行了三年，在前三年应用中 Aurora 齐全满足需要。物联网在六七年前还比拟冷门，智能家居设施没有这么遍及，用户用的不多，但起初随着业务的扩大，近几年设施呈指数级的成长，每年都要翻三到五倍，Aurora 就无奈接受暴增的数据量，特地是物联网响应工夫要求是 10 毫秒以内，即便进行分库分表，拆散集群也达不到涂鸦的业务需要。
Apache Ignite
于是涂鸦开始尝试应用 Apache Ignite，也是一个分布式的 KV 零碎，相似于 PingCAP 的 TiKV，它是基于 JAVA 架构进行数据分片的，其分片比拟大，1G 的数据一个 Partition，并且其扩容没有 TiKV 这么线性。如果涂鸦的业务量翻倍，在机器要扩容的时候就不得不停机，还会有数据失落的危险。这个期间咱们在一个 Ignite 前面下挂了 Aurora 作为灾备，数据会同步写到 Aurora 外面。然而随着业务量的暴增，一个 Ignite 也不能满足涂鸦的业务需要，就须要进行扩容，而 Ignite 架构下扩容的时候要求停机，这是物联网所无奈容忍的。
TiDB 3.0 和 4.0
在 2019 年涂鸦在尝试替换掉 Ignite Cluster 的时候，美国区的存储设备曾经达到 12 台节点。恰逢 PingCAP 在杭州举办 TUG 流动，咱们对 TiDB 3.0 进行了验证测试。然而 TiDB 3.0 上线没有满足涂鸦的要求，因为提早高，吞吐也上不去，尝试了几个月当前只好作罢。
工夫来到 2020 年，TiDB 4.0 上线了。咱们又对 TiDB 4.0 进行了测试，比照 3.0 有十分大的提高，然而提早高，吞吐量有余的问题仍旧存在。这时候 PingCAP 研发团队针对这个问题进行了深入分析，发现次要的耗时就在 SQL PARSER 层，而 TiKV 底层的存储是齐全闲着的，因为涂鸦的写入量大，对提早要求高，齐全达不到预期。
既然呈现的延时都耗费在 SQL PARSER 层，而物联网写入的数据尽管 TPS 高，但业务逻辑没有那么简单，能不能去掉 SQL 层，间接写入 TiKV 层？咱们参照了 PingCAP 提供了 TiKV 的官网 API 文档，声称曾经反对 JAVA、GO 和 Rust，开始了尝试和摸索。
上线利用的后果很惊喜，失去了全公司的认可。之后咱们在寰球各个地区都上线了 TiDB 4.0，通过一年的测试，运行失常没有发现什么问题，本来须要 12 台机器，等同配置下当初只有 3 台机器就能搞定了，也就是说硬件老本只有本来的四分之一。
涂鸦吞吐量上线的时候曾经有 20 万 TPS，以北美区的集群来看，过后的版本是 4.0.8，查问的响应工夫 99% 是 150 微秒，写入是 360 微秒（不到一毫秒），有相似场景的小伙伴们能够尝试一下。
新的挑战：跨区域部署
然而咱们没有快乐多久就遇到了新的挑战，因为 AWS 部署的时候是三个可用区的部署，比方法兰克福一部署就是 ABC 三个区域，三个正本之间通信是要耗费流量，而流量是要免费的，而且涂鸦所有的利用也是部署在三个区，也须要跨区域的调用，TiKV 并没有像 Double 那样同区调用的策略，所以这个费用的老本居高不下，只管涂鸦只有以前四分之一的机器，然而老本比本来还高。目前进行的解决方案是进行了基于 RPC 的压缩，升高网络的流量，但这种流量只能解决 Region 复制的流量，利用代码跨区的复制流量还是没有降下来。
咱们发现呈现这种问题的起因是因为 TiKV 的服务端没有进行服务端过滤，须要把 TiKV 存储的数据取回到本地进行应用程序的过滤，而后再塞回去，这个跟 TiKV 的研发团队进行了沟通，后续的版本可能会推出基于服务端的过滤，升高服务器的负载，流量老本也可能会降落。
降本增效：从 X86 到 ARM 的架构降级
IoT 行业之所以重视降低成本，因为 IoT 行业的毛利率非常低，咱们须要升高每一件模组的老本。在 2020 年 6 月，AWS 推出了 C6G 的产品，性价比声称比上一代 C5 高出 40%，于是咱们对 AWS 的 C6G 进行了尝试，但用 TiUP 编译间接部署的时候发现响应工夫比 X86 架构慢 6 到 7 倍，即 TiUP 部署的是通用编译版本，跟硬件不是那么贴切。通过测试验证，发现现有的 TiKV 版本不反对 SSE 指令集，也就是说目前 TiKV 4.0 应用的 RocksDB 版本是不反对 SSE 指令集的。
SSE 指令集次要是进行 CRC 校验、HASH 和浮点运算的。过后进行了折中计划就是混合部署，TiKV 这边应用的是 X86 架构，其余节点应用的是 ARM 的架构，但这样也带来不不便，如果降级版本的话，指向的镜像一会是 X86 的，一会是 ARM 的，这样会是很麻烦，于是则整体切回了 X86 的架构。
到了往年，TiKV 推出了 5.0 版本，TiKV 5.0 是反对了 aarch 64 优化过的 CRC32C 指令集，也就是 SSE 4.2 指令集，但前提条件是 RocksDB 版本要大于 6.1.2，而 TiKV 5.0 版本的 RocksDB 的版本是 6.4.6，并且在 TiKV 下面能够找到 TiKV 针对 SSE 指令集的优化，也就是说 TiKV 5.0 当初曾经齐全反对 SSE 指令集了，下半年将会纳入重点进行测试，这样的话老本有可能会更大幅的降落。
业务瞻望
将来借助 TiDB 5.0 和 5.1，涂鸦有信念可能承接数倍的业务增长，预计年底 TiKV 的流量又会翻到当初的三到四倍。大数据平台也用了 TiDB 作为大屏展现，并且物联网的设施流水也正在思考应用 TiKV 5.1 作为存储，更大程度上进步易用性，TiDB ARM 版本的部署也在下半年的布局之中。