tidb 调度思考

• 如何保证同一个 Region 的多个 Replica 分布在不同的节点上？更进一步，如果在一台机器上启动多个 TiKV 实例，会有什么问题？

  • 有两种方案，一种是去中心化的，另一种是中心化的。为了分布到不同节点，就必须感知到不同节点，最终目的是为了全局最优化资源利用。
    • 先看中心化的，存在一个服务知道所有的节点的资源利用情况，当创建时节点向该服务发起创建region请求，服务通过分布策略选择其余几个replica节点，并告知申请者这几个replica所在节点，申请者再跟这几个replica节点沟通。从而使replica分布在不同节点。
    • 去中心化的，则每个节点都需要知道尽可能多的服务分布情况，不一定是全部的。通过已知节点，根据分布策略，选择其余几个节点放置replica，再定时根据策略将自身的replica移动到更优的节点去，最终能达到最优分布。

• 如果在同一台机器，则分布策略需要尽量避免分布到相同ip的机器上

• TiKV 集群进行跨机房部署用于容灾的时候，如何保证一个机房掉线，不会丢失 Raft Group 的多个 Replica？

  • 分布策略需要考虑将不同replica分布到多个机房上

• 添加一个节点进入 TiKV 集群之后，如何将集群中其他节点上的数据搬过来?

  • 为了保证数据的可靠性，不能先删掉一个replica，再复制新的节点，只能先复制到新节点，将其将入到group中，再移除老的。

• 当一个节点掉线时，会出现什么问题？整个集群需要做什么事情？如果节点只是短暂掉线（重启服务），那么如何处理？如果节点是长时间掉线（磁盘故障，数据全部丢失），需要如何处理？

  • 掉线时，对该节点的读写就会失败，整个集群在短暂掉线则只需要将读写请求转移到其它副本，如果长时间掉线，则需要将该节点中的副本数据恢复到其它节点去。

• 假设集群需要每个 Raft Group 有 N 个副本，那么对于单个 Raft Group 来说，Replica 数量可能会不够多（例如节点掉线，失去副本），也可能会 过于多（例如掉线的节点又回复正常，自动加入集群）。那么如何调节 Replica 个数？

  • 需要调度者知道当前活跃的replica数量【通过心跳，节点定时上报其拥有的replica】，如果过多，则执行清理，过少则执行恢复

• 读/写都是通过 Leader 进行，如果 Leader 只集中在少量节点上，会对集群有什么影响？

  • 大部分的节点空闲，少部分节点忙死，整体的吞吐量远小于最大利用值。

• 并不是所有的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，这个时候我们需要做什么？

  • 将region进行分拆，使其尽可能平均到整个集群

• 集群在做负载均衡的时候，往往需要搬迁数据，这种数据的迁移会不会占用大量的网络带宽、磁盘 IO 以及 CPU？进而影响在线服务？

  • 会，所以可能在搬迁的时候需要有一个限制，仅在自身及目的机器资源够用的情况下才进行。