江苏龙网

  1. 首页 > 人文 > >

中年TiDB 4.0 新特性在电商行业的探索


作者介绍：冀浩东 ， 转转公司数据库负责人 ， 负责转转公司整体的数据库运营 。初引入 TiDB 解决了哪些问题？
转转使用 TiDB 主要解决了两个问题 ， 一个是分库分表问题 ， 另一个是运维复杂度 。
【中年TiDB 4.0 新特性在电商行业的探索】分库分表是一个非常普遍的问题 ， 会增加我们业务逻辑的复杂性 ， 并且多维度的 mapping 可能导致我们整体性能的下降 。 有了 TiDB 我们可以不用再考虑分库分表 ， 不再需要写那么多的复杂逻辑 。
对于运维复杂度来说 ， TiDB 可以做到快速的水平扩展 ， 无需 DBA 进行复杂的数据搬迁 ， 也无需业务进行流量迁移 ， 并且大表的 Online DDL ， 基本上对于业务感知力度不大 。
产生的新问题引入 TiDB 后 ， 随之也带来了一些新的问题 。
1. 部署慢、管理难 。 TiDB Ansible 在管理多个 TiDB 集群的时候 ， 会有各种各样不同的异常 ， 这会极大的增加我们的运维复杂度 。
2. 热点无法快速定位 。 对于电商场景 ， 数据热点是一个比较常见的问题 。 因为 TiDB 节点众多 ， 无法快速定位热点 KEY ， 需要查询各个节点的日志 ，逐步排查 ，排查成本较高 。
3. 无法快速查看集群状态 。 监控项太多 ， 并且日志都比较分散 ， 某一时间我们要确认集群状态 ， 只能是一步一步来 ， 慢慢的分析 ， 无法迅速对集群异常进行定位 。
4. 数据抽取会增加线上响应延时 。 这是一个非常常见的问题 ， 因为数据抽取也影响我们 TiKV 的性能 。
5. 超大集群无法做到有效的备份 。 对于超大集群的快速的备份和恢复 ， 其实是一个亟待解决的问题 。 之前 ， 我们在数据量规模非常大的情况下才会用到 TiDB ， 这个时候备份其实是非常迫切的 。 之前我们一直是逻辑备份 ， 但是逻辑备份对于我们来讲有效性并不高 。
6. TiKV 线程池的配置复杂及对业务的影响 。 部署 TiKV 时会配置线程数量 ， 需要配置 3 个优先级；对于不同业务的场景需要配置 readpool.storage / readpool.coprocessor 两个 readpool 线程池； 。 随着我们业务的发展与迭代 ， 我们的 SQL 也都不一样 ， 所以在使用 readpool 的时候 ， 方式也不一样 ， 并且如果调整线程配置 ， 会不同程度的影响业务访问 。
TiDB 4.0 解决了哪些问题？那我们接下来看一下 TiDB 4.0 版本可以解决哪些问题 。
1. 集群部署管理问题——TiUP
中年TiDB 4.0 新特性在电商行业的探索
本文插图
之前在使用 TiDB Ansible 管理的时候 ， 其实是比较困难的 ， 并且 TiDB Ansible 自身也存在一些问题 。 TiDB 4.0 开发了一个全新的组件管理工具——TiUP ， 这个工具目前在体验上是非常好的 ， 我们在一分钟内就可以部署完成 3 个 TiDB ， 3 个 PD ，3 个 TiKV 和 1 个 TiFlash ， 这个效果是非常惊艳的 ， 而且 TiUP 也有大量的参数可以查看我们集群的状态 。 我们要特别提醒一点 ， TiFlash 的端口管理非常复杂 ， 有特别多的端口 ， 大家在使用的时候一定要做好 TiFlash 端口管理 。
2. 数据热点问题——Key Visualizer
中年TiDB 4.0 新特性在电商行业的探索
本文插图
在早期 ， 热点问题我们只能通过各种日志去排查 ， 然后慢慢的分析 ， 再找到它 。 现在有一个新的可视化工具叫 Key Visualizer ， 它可以快速直观的观察我们整个集群的热点情况 。 如上图所示 ， 我们将线上集群 ， 通过数据和流量的复制过来以后 ， 把新的流量导过来 。 我们可以看到任意时间点集群的写入情况 ， 例如我们可以看到当前情况下 ， 字节写入量 ， 哪个库 ， 哪张表 ， 以及它的 rowkey 。 在右图 ， 通过集群的明亮程度这个判断指标 ， 就可以看到我们整体 KEY 的一个繁忙程度 ， 这张图整体来讲 ， 这是一个比较符合预期的状态 ， 写入整体比较均匀 。 如果是热点的话 ， 可能会出现一条线 ， 可以明显的看到我们的热点 KEY ， 有了一个工具 ， 我们可以快速的找到热点 KEY 。


推荐阅读


上一篇：移动网络「无线网络」下载速度：2G、3G、4G和5G到底意味着什么？

下一篇：互联网头条、抖音后，谁是字节跳动的新引擎？