TiDB基本架构简单总结

TiDB特点

• 高可用
• 水平拓展
• 事务
• SQL支持

TiDB架构

​ 和MySql不同，TiDB是一个分布式的数据库而不是单个进程,所以整个TiDB是由以下角色组成: TiKV, PD, TiDB, TiSpark。每个角色都是部署在多台机器上的进程组成的集群。

TiKV PD TiDB功能

TiKV

​ TiKV负责数据的存储,对外而言，它就是一个提供key-value存储的引擎。但它存储的并不是离散的Key,而在一个范围内的Key，这个范围内的key-value是存储的基本单元，称为Region。

​ 对不同的数据类型，存储的数据格式如下:

数据类型	key	value
行记录	表ID+行ID	行数据
非唯一索引	表ID+索引ID+索引值	行ID
唯一索引	表ID+索引ID+索引值+行ID	空

​ 而TiKV集群上的单节点上真正负责存储的是FaceBook开源的RocksDB引擎。但RocksDB自身并没有解决单点失效的问题，TiKV采用多副本的方式来解决，而实现则是在RocksDB之上封装一层支持Raft协议，以在多节点之间同步数据。仅对于同一个Region, 只有一个leader节点接收外部对其的读写，其他节点只是用来做备份(即不同机器上的同一个Region 组成一个 Raft group)。

​ 所以对外部而言，TiKV可以认为是一个可以提供无限大容量的K-V存储服务(当磁盘空间不足时，可以比较方便地通过增加机器来拓容)。

PD

​ PD全称是Placement Driver,是对整个TiDB集群管理进行管理的角色。它最重要的功能是存储数据的元数据，即Key和TiKV中节点的对应关系。此外，负责对集群进行调度和负载均衡Region迁移, Region Raft Leader迁移)，以及提供全局唯一递增的事务ID。PD集群也是通过Raft协议保证数据安全，但只有一台机器(Leader)负责处理所有的操作。

TiDB

​ TiDB角色负责对外交互(mysql协议),优化sql之后，向PD获取要读取的Key对应的TiKV节点信息，之后再向TiKV上的Region Raft Leader所在节点发起请求获取数据，再返回客户端。即TiDB是无状态的，不存储任何数据。