一、TiDB整体架构
与传统的单机数据库相比，TiDB具有以下优势：
- 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容
- 支持SQL，对外暴露MySQL的网络协议，并兼容大多数MySQL的语法，在大多数场景下可以直接替换MySQL
- 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明
- 支持ACID事务，对于一些有强一致需求的场景友好，例如：银行转账
- 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景
二、TiDB架构图
在内核设计上，TiDB分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的TiDB系统。对应的架构图如下：
1、TiDB Server：SQL层，对外暴露MySQL协议的连接endpoint，负责接受客户端的链接，执行SQL解析和优化，最终生成分布式执行计划
TiDB层本身是无状态的，实践中可以启动多个TiDB实例，通过负载均衡组件（如LVS、HAProxy、或F5）对外提供统一的接入地址，客户端的
连接可以均匀的分摊在多个TiDB实例上以达到负载均衡的效果。TiDB Server本身并不存储数据，只是解析SQL，将实际的数据读取请求转发给底层的存储节点TiKV(或TiFlash)
2、PD(Placement Driver) Server：整个TiDB集群的元信息管理模块，负责存储每个TiKV节点实时的数据分布情况和集群的整体拓扑结构，提供TiDB Dashboard管控界面，并为
分布式事务分配事务ID。PD不仅存储元信息，同时还会根据TiKV节点实时上报的数据分布状态，下发数据调度命令给具体的TiKV节点，可以说是整个集群的“大脑”。此外，PD本身
也是由至少3个节点构成，拥有高可用的能力。建议部署奇数个PD节点。
3、存储节点
- TiKV Server：负责存储数据，从外部看TiKV是一个分布式的提供事务的Key-Value存储引擎。存储数据的基本单位是Region，每个Region负责存储一个Key Range（从StartKey到
EndKey的左闭右开区间）的数据，每个TiKV节点会负责多个Region。TiKV的API在KV键值对层面提供对分布式事务的原生支持，默认提供了SI（Snampshot Isolation）的隔离级别，这也是
TiDB在SQL层面支持分布式事务的核心。TiDB的SQL层做完SQL解析后，会将SQL的执行计划转换为对TiKV API的实际调用。所以，数据都存储在TiKV中。另外，TiKV中的数据都会自动
维护多副本（默认为三副本），天然支持高可用和自动故障转移。
- TiFlash：TiFlash是一类特殊的存储节点。和普通TiKV节点不一样的是，在TiFlash内部，数据是以列式的形式进行存储，重要的功能是为分析型的场景加速。