课程名称：课程版本（301）+ 3.7.8 How to Deal With Hotspot Issues
学习时长：
30
课程收获：
tidb上的热点 成因以及如何解决。
课程内容：
热点的原因，干预手段，以及处理方法
何为热点，
-
小部分数据提供了远超于其他部分数据的负载。热点会有不同的表现形式比如CPU消耗，qps ，数据流量。
-
tidb底层机制导致局部数据过热。tidb发现热点会自动均衡到其他tikv，除非不能发现，单个热点会导致整个集群性能瓶颈。
-
如果不能消除热点，只是增加tikv节点是不能提升性能。
顺序写
写入请求集中在单个tikv实例。少量tikv实例表现cpu负载高，io压力大。
导致顺序写的原因大概有以下几种
- 业务模式导致顺序写，在表尾部持续的增加数据，
- 表带有的索引包含递增或者递减的吃。
- 带有自增主键的表。
- 新创建的表刚刚写入数据时，会集中写第一个region，导致热点集中。数据量大了就可以进行分裂。
热点小表
特别小的数据被频繁访问，数据集中到一个region中。tikv无法调度手段解决负载问题。导致热点小表的原因
- 大量范围扫描，比如range scan
- 下推计算中包含复杂的表达式
此时需要观察coprocessor metrics 的监控数据。小范围的更新操作也会导致热点小表现象。
region分布倾斜
包含多个region的表，其数据不一定是均匀分布的，此现象成为数据倾斜。如果该表被频繁访问，数据集中的那个region 可能会有性能瓶颈。
- 中等规模的表，因为数据分布不均匀，更可能产生数据倾斜。
- 数据倾斜会导致读，写热点集中
高并发的范围扫描，一定范围的随机更新，插入。
解决方法
- 分区表
Tidb 使用基于hash的分区表解决热点问题，在底层数据分布 不同的分区就是不同的表。表创建完成 就包含多个region，Tidb能更快的完成数据调度。
-
SHARD_ROW_ID_BITS
针对rowid顺序写导致的热点问题。创建表或者通过alter 设置该属性，启用该特性之后 新写入的数据不是严格递增而是随机生成。
-
预分裂region
效果最好，根据表的数据量把region提前分裂合适的数量，可以主动调度将空的region均匀的分布到tikv中。 要求对数据分布比较了解。
-
follow read
主要解决小表的读热点问题。该特性允许从follower replica上读取数据。可以通过tidb_replica_read参数来分配流量set
tidb_replica_read=‘follower’set
tidb_replica_read=‘leader + and + follower’ -
scatter range
pd 将表的region 平均的分布到整个tikv中。
开启curl -X POSThttp://{TiDBIP}:10080/tables/{db}/{table}/scatter
关闭 ，等待调度完成，需要及时关闭
curl -X POST http://{TiDBIP}:10080/tables/{db}/{table}/stop-scatter
-
shuffle leader/region
当前面的方式无法解决region倾斜时，可以采用shuffle leader/region作为非常规手段。
随机移动leader或副本；shuffle leader解决读热点问题；shuffer region解决写热点问题；通过pd-ctl控制调度器
创建：
pd-ctl scheduler add shuffle-region-scheduler
pd-ctl scheduler add shuffle-leader-scheduler
删除：
pd-ctl scheduler remove shuffle-region-scheduler
pd-ctl scheduler remove shuffle-leader-scheduler