TiDB的整体架构
TiDB集群主要包括三个核心组件：TiDB Server、PD Server和TiKV Server。此外，还有用于解决用户复杂OLAP需求的TiSpark组件和简化云上部署管理的TiDB Operator组件。
TiDB核心特性
TiDB具备如下众多特性，其中两大核心特性为：水平扩展和高可用
高度兼容MySQL
大多数情况下，无需修改代码即可从MySQL轻松迁移至TiDB，分库分表后的MySQL集群亦可通过TiDB工具进行实时迁移。
对于用户使用的时候，可以透明地从MySQL切换到TiDB中，只是“新MySQL”的后端存储是“无限的”，不再受制于本地的磁盘容量。在运维使用时也可以将TiDB当做一个从库挂到MySQL主从架构中
分布式事务
TiDB 100%支持标准的ACID事务。
一站式HTAP解决方案
TiDB作为典型的OLTP行存数据库，同事兼具强大的OLAP性能，配合TiSpark，可提供一站式HTAP解决方案，一份存储同事处理OLTP和OLAP，无需传统繁琐的ETL过程。
云原生SQL数据库
TiDB是为云而设计的数据库，支持公有云、私有云和混合云，配合TiDB Operator项目可实现自动化运维，使部署、配置和维护变得十分简单。
水平弹性扩展
通过简单地增加新节点即可实现TiDB的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
真正金融级高可用
相比于传统主从复制方案，基于Raft的多数派选举协议可以提供金融级的100%数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复，无需人工介入。
水平扩展
无限水平扩展是TiDB的一大特点，这里说的水平扩展包括两方面：计算能力和存储能力
TiDB Server负责处理SQL请求，随着业务的增长，可以简单地添加TiDB Server节点，提高整理的处理能力，提供更高的吞吐。
TiKV负责存储数据，随着数据量的增长，可以部署更多的TiKV Server节点解决数据Scale的问题。
PD会在TiKV节点之间一Region为单位做调度，将部分数据迁移到新加的节点上。
所以在业务的早起，可以只部署少量的服务实例（推荐至少部署3个TiKV，3个PD，2个TiDB），随着业务量的增长，按照需求添加TiKV或者TiDB实例。
高可用
高可用是TiDB的另一大特点，TiDB、TiKV、PD这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。
TiDB
TiDB是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的Session，从应用的角度看，会出现单词请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。
PD
PD是一个集群，通过Raft协议保持数据一致性，单个实例失效时，如果这个实例不是Raft的leader，那么服务完全不受影响；如果这个实例是Raft的leader，会重新选出新的Raft leader，自动恢复服务。PD在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个PD实例，单个实例失效后，重启这个实例或者添加新的实例。
TiKV
TiKV是一个集群，通过Raft协议保持数据的一致性（副本数量可配置，默认保存三个副本），并通过PD做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有Region。对于Region中的leader节点，会中断服务，等待重新选举；对于Region中的follower节点，不会影响服务。当某个TiKV节点失效，并且在一段时间内（默认30分钟）无法恢复，PD会将其上的数据迁移到其他的TiKV节点上。
