概念

store：对应存储节点，这里的节点指的是TIKV实例，不是物理主机

peer/region/raft group:region是集群内部的一段连续数据，也是调度的最小单位，默认96M。每一份数据会有三个不同的副本，每一个副本就是一个peer，这三个副本就构成了一个region的raft group。对于region来说，我们会把所有的key按照字节进行排序，排序过后会产生一个大大的sort map，然后对着一个大大的sort map进行拆分，把大的sort map拆分成为一个个的region。

leader/follower/learner:对应region的三种不同角色，leader负责对外提供读写服务，follower从leader处通过raft协议同步数据，learer是一种特殊的角色，不参与投票

region split：region的分裂，比如在对表从mysql同步到tidb的时候涉及到对表的大量insert操作，这个时候region的分裂会影响导入的速度，可以通过tidb Lightning提高处理速度。

pending/down：对于region的特殊状态，pending状态表示与leader 的数据差异较大，不能被选举。长时间没有收到对应peer的信息那么peer的状态就会被标记为down

scheduler：调度策略，主要有balance-leader-scheduler/balance-region-scheduler/hot-region-scheduler和evict-leader-scheduler。

调度流程

    对region进行调度一般有信息收集、生成调度、执行调度三个流程

    信息收集，主要是通过tikv周期性发送给PD的心跳信息来获取，心跳有两种一种是storeheart记录了store的容量、空闲空间、流量等等信息；另外一种是region heartbeat记录了region层面的信息。

    生成调度，根据需求（比如具体的调度策略是leader优先还是region优先）、限制和从PD采集的信息，综合分析后生成调度计划，这里提到的限制主要有不选择状态异常的副本、pending状态的不能作为leader、不直接干掉leader等等~~~

    执行调度，在调度被生成之后剩下的就是对调度的执行了，在执行对应的operation的时候是不会直接执行的，而是先放入到执行等待队列里面，然后用一定的并发去执行。

关于Balance

    Region 负载均衡调度主要依赖 balance-leader 和 balance-region 这两个调度器，虽然说他们两者的目的都是把region调度走，让region的分布变得合理，但是两个调度的侧重点是不一样的，前者更加关心对负载的分布，希望将leader分开以便于分散客户端的读写压力，但是后者则侧重于对存储空间的分配，大家都存一样多的数据才是王道，这两个的侧重点不一样。不管是哪一种调度器，都是具有对region的打分实现，比如说对于balance-leader的打分算法就较为简单，就是通过对leader的size（注意是size，不是count）打分实现的。

    当然，在打分的过程中是肯定可以调整权重的，可以通过设置region或者主机的权重控制对region的调度。

关于集群拓扑感知

    为什么要感知？为了通过调度使不同 Region 的各个副本尽可能分散，保证高可用和容灾。

    怎么感知？主要还是通过pd在后台不断的对region做扫描分析来实现对region拓扑的感知

    谁去做？负责这个工作的组件叫做replicachecker,它的作用就是去分析region的拓扑状态，但是他依赖于lcation-lables这个变量的配置。

region状态指标和查询

operation状态指标

    scheduler operaction create：operation创建的情况

    operation finish duration:OP的耗时情况

    operation step duration，op中不同操作的耗时情况

    要查看这些指标可以在grafana或者通过operater show的方式进行查看。

balance状态指标 

    Store Leader/Region score：展示每个 Store 的得分

    Store Leader/Region count：展示每个 Store 的 Leader/Region 数量

    Store available：展示每个 Store 的剩余空间

    查看这些指标依然可以通过grafana-->PD-->statistics-->balance页面做查看