一句说来形容TiDB就是：分布式、强一致、可扩展、并且支持SQL的关系型数据库，借用官方的一张架构图

分三层架构：

TiDB层是：无状态计算层

PD层是：集群管理，也就是存储的元信息

TiKV层是：分布式键值存储层

对于本地key-vale存储，是基于facebook公司开发的嵌入式存储引擎RocksDB，而RocksDB的主要设计目标是保证存取快速存储器和高负载服务器更高效，保证充分利用Flash或RAM子系统提供的高速率读写，支持高效的查找和范围scan，支持高负载的随机读、高负载的更新操作或两者的结合。其架构应该支持高并发读写和容量大增时系统的一致性。

虽然解决了单节点故障问题，但是这种架构下有一个问题，如果数据量不断的增大，单个节点无法容纳的时候，就引用写的问题，为了解决这个问题，TiDB做了分片，常用的分片方法有hash和range两种类型，虽然hash解决了数据热点问题，但如果要做范围扫描的话，hash需要扫描多个存储节点，显然不合适，因此Tidb选择了range分片

从图上看，引用Region，并且这个Region是自动创建，后续的复制也是基于Region，具体怎么实现呢，继续引用官方的解决方案图，假如有A、B、C、D四个节点，其中A节点存储空间不足，添加节点E，数据自动实现迁移和平衡

关于MVCC TIDB又是如何实现的呢？根据官方法解释是在key的后面添加vesion进行实现，通过PD组件进行分配，每个key的多个版本是共享key的前缀，多而实现在逻辑上和物理上排列在一起，通过verion设置成历史某个时间，可以很容易实现历史某一时间点的查询，这点跟ORACLE闪回查询有点像，但是这个历史时间点能够支持多长时间呢？是不是跟oracle一样，只是支持有限的时间点？

事务模型：

采用Google Percolator模型，主要的优点是乐观事务模型，这点区别于oracle和mysql的悲观事务模型，其实际是提示的时候检测冲突，隔离级别采用的是Snapshot Isolcation

整个TiKV架构如下：

客户端第一次访问时，首选访问PD确认需要访问的Region在什么位置，谁是leader，然后将这些信息缓存在客户端，下次访问时直接访问，那么PD是什么架构呢

PD本身就是一个集群，要求三个节点，存储节点元信息等，对集群进行负载均衡调度

系统管理员可以通过PD配置调度策略，同时PD根据整个集群的负载程度确定Region迁移调度

关于SQL Layer层的实现

底层是key-value模型，为了支持SQL，必须实现关系表到key-value的应射，支持全局索引以及并行查询、函数、以及大数据的分析，下图是TiDB的整个存储结构图

这种存储结构会使查询更加高效

整个SQL Layer架构

还有一个最大的优点就是在oracle和mysql中修改表结构是比较麻烦的事情，但是TiDB是可以在线修完成DDL操作，TiDB整个架构图

TiDB官方提供了很多免费的中文视频，很赞