---
title: 'TiDB x 涂鸦智能 | 涂鸦智能选型 TiKV 的心路历程'
date: '2023-06-29T18:26:10+08:00'
status: publish
permalink: /case/user-case-tuya
author: xuliwen
excerpt: 'TiKV 支持 JAVA、GO 和 Rust 多种语言，帮助涂鸦降低响应时间、提高吞吐量，同等配置下减少机器使用数量。在满足涂鸦暴增的业务需求同时，降低了涂鸦的硬件成本。'
type: case
id: 1243
thumbnail: https://img1.pingcap.com/files/2023/02/涂鸦智能.jpeg
industry:
    - 物联网
scene:
    - '实时 HTAP'
company_desc:
    - '涂鸦智能是一个全球化 loT 开发平台，基于全球公有云，实现智慧场景和智能设备的互联互通，涵盖硬件开发工具、全球公有云、智慧商业平台开发，提供从技术到营销渠道的全面赋能。目前，涂鸦在国内外已有超过十万家合作伙伴，生态客户数量达到 32 万+，涉及制造业、零售业、运营商、地产、养老、酒店等。'
white_paper_link:
    - ''
banner_image:
    - ''
---
业务挑战
----

与传统行业不同，物联网行业中的业务没有低峰点，写入量一直都非常大。涂鸦的设备在全球每天需处理 840 亿次请求，平均请求处理次数高峰达到 150 万 /秒，平均响应时间要求小于 10 毫秒。

目前很多人家里都会使用到诸如智能电灯、扫地机器人等智能设备，这些设备联网后涂鸦就会赋予设备通讯的能力。而智能设备的各种定时触发信息，如摄像头的巡更、扫地机器人的位置信息都需要上报给涂鸦的 Zeus 平台。该平台在涂鸦平台中负责处理数据上报，应用网关会将收集到的 MQTT 消息发送到 Kafka 和 NSQ 上，Zeus 系统会消费这些消息数据并进行解密，处理后再将数据放到存储中。从 Zeus 到存储之间的这段产品选型对涂鸦来说是一项巨大挑战。

早期涂鸦采用了 Aurora 方案，但随着近几年业务的扩展，物联网设备呈指数级成长，每年都要翻三到五倍， Aurora 无法承受暴增的数据量，即使进行分库分表，拆散集群也无法满足涂鸦的业务需求。

之后涂鸦开始尝试使用分布式 KV 系统—— Apache Ignite，虽然解决了部分扩容问题，但 Ignite 在扩容时要求停机，这对于物联网而言是无法容忍的。

解决方案
----

在与 PingCAP 研发团队进行深入沟通后，涂鸦参照着 TiKV 官方 API 文档，对 TiDB 开始了尝试和探索。物联网写入的数据虽然 TPS 很高，但业务逻辑并不复杂，经过测试，涂鸦发现使用 TiDB 时， SQL PARSER 层耗时较大，而 TiKV 底层的存储是完全闲着的。因此涂鸦尝试去掉 SQL 层，直接将数据写入 TiKV。

尝试的结果令涂鸦感到惊喜，于是涂鸦在全球各个地区都上线了 TiDB 4.0。上线时吞吐量达到了 20 万 TPS，查询响应时间 99% 达到了 150 微秒（北美区），不到一毫秒。而原本需要 12 台机器的配置，应用 TiDB 后只要 3 台机器就能搞定，硬件成本只有原本的四分之一，大大节省了硬件成本。目前，TiDB 已经在涂鸦平台稳定运行一年时间。

在今年新推出的 TiKV 5.0 版本中，加入了对 SSE 指令集的支持与优化，这将使得涂鸦可以使用 ARM 架构来降低模组的成本，进一步大幅降低平台的整体成本。

业务收益
----

- 通过引入 TiDB ，涂鸦轻松做到海量数据实时响应；
- TiKV 线性扩容降低了停机风险，最大程度避免数据丢失，满足了涂鸦暴增的业务量需求；
- 单独使用 TiKV 满足延迟要求，大大提高涂鸦平台的吞吐能力。