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是无状态的,不存储任何数据。

原文地址:https://www.cnblogs.com/Me1onRind/p/11337079.html