分布式NewSQL数据库TiDB总体架构

这篇文章将向大家介绍TiDB数据库系统的总体架构，本文参考了pingcap官方文档，并补充了少量内容。在介绍TiDB总体架构时，还简要描述了每一个组件的可扩展性和高可用性。

TiDB 分布式数据库集群如上图所示主要分为三个组件：
(1) TiDB Server
TiDB Server 负责接收SQL请求，处理SQL 相关的逻辑，并通过PD 找到存储计算所需数据的TiKV 地址，与TiKV交互获取数据，最终返回结果。
TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或F5）对外提供统一的接入地址。
为了确保靠可用，推荐至少部署两个TiDB实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，只会影响正在这个实例上进行的Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个TiDB实例失效后，可以重启这个实例或者部署一个新的实例。

(2) PD Server
Placement Driver (简称PD) 是整个集群的管理模块，其主要工作职责有三个：一是存储集群的元信息（某个Key 存储在哪个TiKV 节点）；二是对TiKV 集群进行调度和负载均衡（如Region的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务ID（全局事物时间戳）。
PD 是一个集群，其内置了etcd组件负责集群元数据的存储和管理，它采用Raft分布式共识协议保证所存储数据多副本的强一致性。PD集群可以水平扩展，需要部署奇数个节点，一般线上推荐至少部署3 个节点以保证PD集群的高可用。
当PD 集群中的某个实例失效时，如果这个实例不是Raft 的leader，那么服务完全不受影响；如果这个实例是Raft 的leader，那么剩余的PD实列会重新选出新的Raft leader，自动恢复服务。PD在选举的过程中无法对外提供服务，这个时间大约是3 秒钟。推荐至少部署三个PD 实例，单个实例失效后，重启这个实例或者添加新的实例。

(3) TiKV Server
TiKV Server 负责存储数据，是整个TiDB数据库集群的存储引擎。从外部看，TiKV 是一个分布式的提供事务和强一致性的Key-Value 存储引擎。存储数据的最小粒度是记录行（也就是一个key-value对），存储数据的基本逻辑单位是Region，它是PD进行数据调度的基本单位，也是TiKV集群中数据复制的基本单位。每个Region 负责存储一个Key Range （从StartKey 到EndKey 的左闭右开区间）的数据，每个TiKV节点上会有多个Region 。TiKV 使用Raft 协议做复制，保证数据的一致性和高可用容灾。副本以Region 为单位进行管理，不同节点上的多个Region 副本构成一个Raft Group（副本数量可配置，默认保存三副本）。数据在多个TiKV 之间的负载均衡由PD 调度，这里也是以Region 为单位进行调度。
TiKV 集群可以水平扩展，需要部署奇数个节点，一般线上推荐至少部署3 个节点以保证PD集群的高可用。
当单个TiKV实例失败时，会影响这个实例中存储的所有Region。对于这些Region 中的leader，会中断服务，等待重新选举；对于Region 中的Follower 节点，不会影响服务。当某个TiKV 节点失效，并且 在一段相对较长的时间内（默认30 分钟）无法恢复，PD 会将其上的数据迁移到其他的TiKV节点上。