一，TiDB集群简介
TiDB 是 PingCAP 公司基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库。
TiDB 具备如下 NewSQL 核心特性：
- SQL支持 （TiDB 是 MySQL 兼容的）
- 水平线性弹性扩展
- 分布式事务
- 跨数据中心数据强一致性保证
- 故障自恢复的高可用
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景。
TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。
二、TiDB整体架构
深入了解TiDB的水平扩展，要了解TiDB的整体架构
TiDB 集群主要分为三个组件：
TiDB Server
TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。 TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。
PD Server
Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个： 一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。
PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。
TiKV Server
TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range （从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。
三、特性特性
1、水平扩展
无限水平扩展是TiDB的一大特点，这里水平扩展说的包括2方面：计算能力和存储能力。
TiDB Server负载处理SQL请求，随着业务的增长，可以简单的添加TiDB Server节点，提高整体的处理能力，提高更高的吞吐。
TiKV Server负载存储数据，随着数据量的增长，可以部署更多的TiKV Server节点解决数据的Scale问题，如果存储不足，PD Server会将部署数据迁移到新的节点上。
因此在早期，可以部署少量的服务实例（推荐至少部署3个TiKV Server、3个PD Server、2个TiDB Server），随着业务量的增长，按照需求添加TiKV或者TiDB实例
2、高可用
高可用是TiDB的另一大特点，TiDB、PD、TiKV这3个组件都能容忍部分实例失败，从而不影响整个集群的可用性。
a、TiDB
TiDB是无状态的，推荐至少2个实例，前段通过负载均衡组件对外提供服务。当单个实例失效的时候，会影响正在这个实例上进行的Session，从应用的角度看，会出现单次请求失败的情况，重新连接即可获取服务（有些像连接池连接失效重新获取）。单个实例失败后的处理，和mysql高可用的单个实例处理方法类似，重启实 例或者部署一个新的实例。
b、PD
PD是一个集群，通过Raft协议保持数据的一致性 ，单个实例失效时候，如果这个实例不是Raft的leader，那么服务完全不受影响；如果这个实例是Raft的leader，会重新选出新的Raft leader，自动恢复服务。当然在重新进行选举的如果从中无法提供对外服务，这个时间约是3秒钟，推荐至少部署3个PD实例；单个实例失败后，添加新的实例或者重启这个实例，以保证集群永远有3+实例。
c、TiKV
TiKV是一个集群，通过Raft协议保持数据的一致性（副本数量可配置，默认3副本），通过PD server进行复制均衡调度；当单个节点失效时，会影响这个节点上存储的所有Region。对于Region中的Leader节点，会中断服务，等待重新选举；对于Region中的Follower节点，不会影响服务。因此当某个TiKV节点失效，并且在一段时间内（默认10分钟）无法恢复，PD会将其上的数据迁移到其它的TiKV节点上。