【精选实践】TiDB 在 360 商业化的应用和实践

2022 年 7 月 11 日
本文字数：3906 字
阅读完需：约 13 分钟

原文来源：https://tidb.net/blog/bdf3f700
作者：代晓磊，TUG 大使、360 数据库运维专家

本文主要介绍 TiDB 在 360 商业化业务线的应用实践，以及出现写热点时的优化思路和方法。

业务简介以及数据库选型

360 商业化广告主实时报表业务简介

广告主关键词实时统计报表业务，流程是：业务数据入 Kafka，每 30 秒会有程序读 Kafka 数据进行聚合存储到 TiDB 中，每批次会有几十万的写入，单表数据量 1.2~1.5 亿。

写入场景

业务写入 SQL 主要是：insert on duplicate key update，Batch 为 100，并发为 300。并且每天创建一张新表进行写入，写入初期由于没有重复的 uniq_key，所以主要是 insert，随着数据量到达 2000 多万，update 的操作越多。

表结构如下：

数据库选型：MySQL or TiDB?

说到 TiDB 不得不提 TiDB 的架构，结合架构说说 TiDB 的特性：

可在线扩展：TiDB Server/PD/TiKV 这 3 大核心模块各司其职，并且支持在线扩容，region 自动 balance，迁移过程对业务无感知。
高可用：基于 Raft 的多数派选举协议实现了金融级别的数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
无缝迁移：支持 MySQL 协议，业务迁移无需修改代码。
丰富的监控 + 运维工具：

监控：基于 Prometheus + Grafana 的丰富监控模板 ;
运维工具：tidb-ansible 部署 + 运维 ;
TiDB Data Migration(DM)：将数据从 MySQL 迁移 + 同步的工具 ;
TiDB Lightning：可以从 CSV 文件或者第三方数据源将数据直接导入到 TiKV;
TiDB Binlog：备份工具，也可以重放到 Kafka/MySQL/TiDB 等数据库。

TiDB 最核心的应用场景是：大数据量下的分库分表，比如经常需要 1 拆 4，4 拆 8 等数据库无限制拆分情况，并且业务端还需要自己维护路由规则，TiDB 良好的扩展性解决了这些问题。

为了能满足这么大的写入量，曾经尝试过单实例 MySQL 去抗请求，测试完后发现单实例 MySQL 压力较大，为了分散写压力，又想走 MySQL 分库分表这种老路，TiDB 3.0.0GA 后，我们拿离线数据进行了压测，2 小时 1.5 亿的数据存储 (tps:2W/s)，整个系统负载良好，所以决定使用 TiDB。

系统配置

服务器硬件配置：

CPU: E5-2630v2*2;

MEM: 16G DDR3*8;

Disk: Intel S3500 300G*1; flash: 宝存 1.6T*1;

Net: 1000M*2

服务器系统版本：CentOS Linux release 7.4.1708 (Core)

TiDB 的版本：tidb-ansible-3.0.0

规模：2.8 亿 / 天

存储：3.8T

TiDB 部署架构图：

注：PD 跟 TiDB 共用服务器

写热点问题

1. 热点现象描述

接到业务反馈：从 7 月份开始， Kafka 队列里面有大量的数据累积，等待写入 TiDB，Kafka 高峰期的待写入 lag 有 3000 多万，接口的调用时间由之前的 1s 变成现在的 3s~5s。我登录 TiDB 发现，单表的数据量由之前的 7000 飙升到 1.2~1.5 亿，虽然数据量几乎翻了一倍，但单条 insert 的性能不至于这么差。

下图是 Kafka 当时的待写入的 lag 情况：

2. 查看 Grafana Overview 监控

TiKV 监控项：scheduler pending commands，发现 TiKV 227 节点大量等待的命令。

TiKV 监控项：CPU 使用也可能看出热点都集中在 227 这个 TiKV 节点上。

解决方案

DBA 可以根据线上写热点表的表结构不同而采用不同的优化方案。对于 PK 非整数或没有 PK 的表，数据在 insert 时，TiDB 会使用一个隐式的自增 rowid，大量的 Insert 会把数据集中写入单个 region，造成写热点。

此时可以使用 SHARD_ROW_ID_BITS 来打散热点，如果业务表可以新建的话 (比如我们的报表业务是按天分表)，可以结合 pre-split-regions 属性一起在建表阶段就将 region 打散。如果不满足上面的表结构（比如就是以自增 ID 为主键的表），可以使用手动 split region 功能。上面的两种方法都需要 PD 的参数调整来加快热点 region 的调度。

手动 split 热点

因为我的表结构是 ID 自增主键，所以我先使用手动 split 热点。

（1）找出热点 TiKV 的 store number

在 tidb-ansible 的 scripts 目录下 table-regions.py 脚本可以查看热点表和索引 region 分布情况：

python table-regions.py --host=tidb_host –port=10080 db_name tb_name[RECORD – db_name.tb_name] - Leaders Distribution:total leader count: 282store: 1, num_leaders: 1, percentage: 0.35%store: 4, num_leaders: 13, percentage: 4.61%store: 5, num_leaders: 16, percentage: 5.67%store: 7, num_leaders: 252, percentage: 89.36%

复制代码

通过执行上面的命令，能查看热点表都在 store 7(227 服务器) 这个 TiKV 节点。

（2）查看热点的表 regions 分布：

curl http:// ${tidb_host}:10080/tables/db_name/tb_name/regions > regions.log

（3）手动切分 region：

切分命令如下

pd-ctl -u http:// ${pd_host}:2379 operator add split-region region_id

使用命令找出 store7 的 region id：

grep -B 3 ": 7" regions.log |grep "region_id"|awk -F': ' '{print $2}'|awk -F',' '{print "pd-ctl -u http://pd_host:2379 operator add split-region",$1}' > split_region.sh

（4）执行切分脚本就实现了 region 切分：

sh split_region.sh

参数优化

(1) 调整 PD 调度参数

pd-ctl -u http://pd_host:2379 config set 参数值

“hot-region-schedule-limit”: 8

“leader-schedule-limit”: 8,

“region-schedule-limit”: 16

上面 3 个参数分别是控制进行 hot-regionleader egion 调度的任务个数。这个值主要影响相应 Region balance 的速度，值越大调度得越快，但是也不宜过大，可以先增加一倍看效果。

(2) TiKV 参数之：sync-log

跟 MySQL 的 innodb_flush_log_at_trx_commit(0,1,2) 类似，TiDB 也有一个 sync-log 参数，该参数控制数据、log 落盘是否 sync。注意：如果是非金融安全级别的业务场景，建议设置成 false，以便获得更高的性能，但可能会丢数据。

该参数是 TiKV 参数，需要调整 tidb-ansible 下 conf 目录中 tikv.yml，然后使用下面的命令，只滚动升级 TiKV 节点。

ansible-playbook rolling_update.yml –tags=tikv

注：本次优化保持默认 true

优化后查看效果方式

(1) 命令查看 leader 调度情况：

pd-ctl -u http:// ${pd_host}:2379 operator show leader

(2) 查看 Grafana 监控图

PD 监控模块中：scheduler 模块 ->Scheduler is running->balance-hot-region-scheduler 看这个是否有值，这个有值代表有热点 region 调度。

PD 监控模板中：Operator->Schedule operator create->balance-leader

其他就是从 Overview 中，TiKV 模块的 Leader、Region，CPU、Scheduler pending commands 等变化情况。

终极大招之表结构优化

通过手 split 的方式并没有较好地解决业务的写热点问题，我们采用了 SHARD_ROW_ID_BITS 结合 PRE_SPLIT_REGION 的方式来打散热点。

对于 PK 非整数或没有 PK 的表，在 insert 的时候 TiDB 会使用一个隐式的自增 rowid，大量 INSERT 会把数据集中写入单个 Region，造成写入热点。通过设置 SHARD_ROW_ID_BITS 来适度分解 Region 分片，以达到打散 Region 热点的效果。使用方式：

ALTER TABLE t SHARD_ROW_ID_BITS = 4; # 值为 4 表示 16 个分片

由于我们的表每天都会新建，所以为了更好的效果，我们也使用了 PRE_SPLIT_REGIONS 建表预切分功能，通过配置可以预切分 2^(pre_split_regions-1) 个 Region。

下面的最新的表结构，重要的优化是：删除了自增主键 ID，建表时添加了 SHARD_ROW_ID_BITS 结合 PRE_SPLIT_REGION 配置。