作者： 18515065291 原文来源：https://tidb.net/blog/d97574e1

                   TiDB订单业务集群优化分享                          --2019-11-12 58公司 春雷

1、汇总

1.1、问题

问题：某订单业务准备迁移，开启双写后，发现业务的消息有积压，关闭双写后即恢复

业务层分析：业务开启双写的方式为：异步处理，线程池，其中一个线程池消费慢的话，会导致整体变慢

数据库层分析：数据库消费能力差 (SQL 执行时间长)，导致上游业务出现堆积

处理及优化：

业务层：后期会改成消息队列的方式，即消费慢的话也不会影响整体

数据库层：优化数据库层，减少 SQL 执行时间

1.2、优化前后对比

2、具体

2.1、集群信息

2.2、当前问题

2.3、当前问题监控情况

2.3.1、 Raft store CPU

2.3.2、SQL 执行时间

2.3.3、cpu 情况

2.3.4、IO 情况

3、优化

3.1、优化具体

<1>版本升级

3.0.2 升级至 3.0.5 完成

<2>更改 tikv 的参数

store-pool-size

• 处理 raft 的线程池线程数。

• 默认值：2

• 最小值：大于 0

[raftstore]的 store-pool-size 2 改成 4 完成

<3>开启静默 region 完成

用于减少 raftstore CPU 的消耗

将 raftstore.hibernate-regions 配置为 true

<4>开启 region merge

Region merge 指的是为了避免删除数据后大量小甚至空的 Region 消耗系统资源，通过调度把相邻的小 Region 合并的过程。 在后台遍历，发现连续的小 Region 后发起调度。

4、优化前后对比

4.1、优化前后对比

4.2、优化前后的监控情况

4.2.1、优化前后 SQL 执行时间

【优化前】

【优化后】

4.2.2、 优化前后 Raft store CPU 情况

【优化前】

【优化后】

4.2.3、 优化前后 CPU 情况

【优化前】

【优化后】

4.2.4、 优化前后 IO 使用情况

【优化前】

【优化后】

4.2.5、优化前后各个 tikv 实例的 region 等情况

【优化前】

【优化后】

相关阅读：

再记一次业务优化