TiDB 整体架构

TiDB 整体架构

TiDB Server: 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。

PD: 是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。

TiKV Server: 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎

TiDB 数据库的存储

TIKV 分层架构
Transaction：分布式 key-values 存储引擎
MVCC：高度分层
Raft：通过Raft协议保证数据一致性
Local KV Storage：不依赖于分布式文件系统

TiKV 数据存储的两个关键点：
这是一个巨大的 Map（可以类比一下 C++ 的 std::map），也就是存储的是 Key-Value Pairs（键值对）
这个 Map 中的 Key-Value pair 按照 Key 的二进制顺序有序，也就是可以 Seek 到某一个 Key 的位置，然后不断地调用 Next 方法以递增的顺序获取比这个 Key 大的 Key-Value。

Raft 提供几个重要的功能：
Leader（主副本）选举
成员变更（如添加副本、删除副本、转移 Leader 等操作）
日志复制

TiKV 利用 Raft 来做数据复制，每个数据变更都会落地为一条 Raft 日志，通过 Raft 的日志复制功能，将数据安全可靠地同步到复制组的每一个节点中。不过在实际写入中，根据 Raft 的协议，只需要同步复制到多数节点，即可安全地认为数据写入成功。

通过单机的 RocksDB，TiKV 可以将数据快速地存储在磁盘上；通过 Raft，将数据复制到多台机器上，以防单机失效。数据的写入是通过 Raft 这一层的接口写入，而不是直接写 RocksDB。通过实现 Raft，TiKV 变成了一个分布式的 Key-Value 存储，少数几台机器宕机也能通过原生的 Raft 协议自动把副本补全，可以做到对业务无感知。

Region（TiKV 选择了第二种方式）
Hash：按照 Key 做 Hash，根据 Hash 值选择对应的存储节点。
Range：按照 Key 分 Range，某一段连续的 Key 都保存在一个存储节点上。

将数据划分成 Region 后，TiKV 将会做两件重要的事情：
以 Region 为单位，将数据分散在集群中所有的节点上，并且尽量保证每个节点上服务的 Region 数量差不多。
以 Region 为单位做 Raft 的复制和成员管理。

SQL层架构

用户的 SQL 请求会直接或者通过 Load Balancer 发送到 TiDB Server，TiDB Server 会解析 MySQL Protocol Packet，获取请求内容，对 SQL 进行语法解析和语义分析，制定和优化查询计划，执行查询计划并获取和处理数据。数据全部存储在 TiKV 集群中，所以在这个过程中 TiDB Server 需要和 TiKV 交互，获取数据。最后 TiDB Server 需要将查询结果返回给用户

TiDB 数据库的调度
PD (Placement Driver) 是 TiDB 集群的管理模块，同时也负责集群数据的实时调度。

TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个副本 (Replica)，这些副本会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 Raft log。

PD模块催生的场景
为了提高集群的空间利用率，需要根据 Region 的空间占用对副本进行合理的分布。
集群进行跨机房部署的时候，要保证一个机房掉线，不会丢失 Raft Group 的多个副本。
添加一个节点进入 TiKV 集群之后，需要合理地将集群中其他节点上的数据搬到新增节点。
当一个节点掉线时，需要考虑快速稳定地进行容灾。
从节点的恢复时间来看
如果节点只是短暂掉线（重启服务），是否需要进行调度。
如果节点是长时间掉线（磁盘故障，数据全部丢失），如何进行调度。
假设集群需要每个 Raft Group 有 N 个副本，从单个 Raft Group 的副本个数来看
副本数量不够（例如节点掉线，失去副本），需要选择适当的机器的进行补充。
副本数量过多（例如掉线的节点又恢复正常，自动加入集群），需要合理的删除多余的副本。
读/写通过 Leader 进行，Leader 的分布只集中在少量几个节点会对集群造成影响。
并不是所有的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，需要通过调度进行负载均衡。
集群在做负载均衡的时候，往往需要搬迁数据，这种数据的迁移可能会占用大量的网络带宽、磁盘 IO 以及 CPU，进而影响在线服务。

调度的需求
第一类：作为一个分布式高可用存储系统，必须满足的需求，包括几种：
副本数量不能多也不能少
副本需要根据拓扑结构分布在不同属性的机器上
节点宕机或异常能够自动合理快速地进行容灾
第二类：作为一个良好的分布式系统，需要考虑的地方包括：
维持整个集群的 Leader 分布均匀
维持每个节点的储存容量均匀
维持访问热点分布均匀
控制负载均衡的速度，避免影响在线服务
管理节点状态，包括手动上线/下线节点

调度的基本操作
调度的基本操作指的是为了满足调度的策略。上述调度需求可整理为以下三个操作：
增加一个副本
删除一个副本
将 Leader 角色在一个 Raft Group 的不同副本之间 transfer（迁移）。
刚好 Raft 协议通过 AddReplica、RemoveReplica、TransferLeader 这三个命令，可以支撑上述三种基本操作。

调度的策略
一个 Region 的副本数量正确
当 PD 通过某个 Region Leader 的心跳包发现这个 Region 的副本数量不满足要求时，需要通过 Add/Remove Replica 操作调整副本数量。出现这种情况的可能原因是：
某个节点掉线，上面的数据全部丢失，导致一些 Region 的副本数量不足
某个掉线节点又恢复服务，自动接入集群，这样之前已经补足了副本的 Region 的副本数量过多，需要删除某个副本
管理员调整副本策略，修改了max-replicas的配置
一个 Raft Group 中的多个副本不在同一个位置
注意这里用的是『同一个位置』而不是『同一个节点』。在一般情况下，PD 只会保证多个副本不落在一个节点上，以避免单个节点失效导致多个副本丢失。在实际部署中，还可能出现下面这些需求：
多个节点部署在同一台物理机器上
TiKV 节点分布在多个机架上，希望单个机架掉电时，也能保证系统可用性
TiKV 节点分布在多个 IDC 中，希望单个机房掉电时，也能保证系统可用性
这些需求本质上都是某一个节点具备共同的位置属性，构成一个最小的『容错单元』，希望这个单元内部不会存在一个 Region 的多个副本。这个时候，可以给节点配置 labels 并且通过在 PD 上配置 location-labels 来指名哪些 label 是位置标识，需要在副本分配的时候尽量保证一个 Region 的多个副本不会分布在具有相同的位置标识的节点上。
副本在 Store 之间的分布均匀分配
由于每个 Region 的副本中存储的数据容量上限是固定的，通过维持每个节点上面副本数量的均衡，使得各节点间承载的数据更均衡。
Leader 数量在 Store 之间均匀分配
Raft 协议要求读取和写入都通过 Leader 进行，所以计算的负载主要在 Leader 上面，PD 会尽可能将 Leader 在节点间分散开。
访问热点数量在 Store 之间均匀分配
每个 Store 以及 Region Leader 在上报信息时携带了当前访问负载的信息，比如 Key 的读取/写入速度。PD 会检测出访问热点，且将其在节点之间分散开。
各个 Store 的存储空间占用大致相等
每个 Store 启动的时候都会指定一个 Capacity 参数，表明这个 Store 的存储空间上限，PD 在做调度的时候，会考虑节点的存储空间剩余量。
控制调度速度，避免影响在线服务
调度操作需要耗费 CPU、内存、磁盘 IO 以及网络带宽，需要避免对线上服务造成太大影响。PD 会对当前正在进行的操作数量进行控制，默认的速度控制是比较保守的，如果希望加快调度（比如停服务升级或者增加新节点，希望尽快调度），那么可以通过调节 PD 参数动态加快调度速度。

调度的实现
PD 不断地通过 Store 或者 Leader 的心跳包收集整个集群信息，并且根据这些信息以及调度策略生成调度操作序列。每次收到 Region Leader 发来的心跳包时，PD 都会检查这个 Region 是否有待进行的操作，然后通过心跳包的回复消息，将需要进行的操作返回给 Region Leader，并在后面的心跳包中监测执行结果。