从今天开始就准备学习TIDB数据库，初期基础差,学习可能会比较困难入门后可能就会好很多
TIDB 是一个分布式，强一致的可水平扩展的关系型数据库，在TIDB 设计之初，聚焦了四个设计的要点
1 水平扩展， 在设计之初水平扩展是最基本的需求，通过添加机器的方式扩展，存储的能力和计算的能力
2 高可用， TIDB 作为分布式数据库，节点众多，对于节点失效和数据库滚动升级，需要解决少量节点失效的问题
3 ACID 事务， 虽然部分数据库为了更高效的存储和处理数据，抛弃了SQL和事务，但在生产中的交易场景中，事务是非常重要的，另一个主要的原因在于如果事务的问题不在本地存储，而是业务解决或者中间件解决，这样做比较难做到高效
4 SQL 支持，提供MYSQL 的支持，让整体使用数据库变得简单
下面是一张TIDB 的结构图
TIDB 存储引擎是TIKV 数据库存储引擎，采用了分层的架构来实现
1 transaction
2 MVCC
3 raft
4 local kv storage
容灾与特点
高度分层，底层为ROCKSDB，通过raft来进行数据存储的高可用， 高度分层的主要原因是可以更独立的进行层次的切换。通过多副本的方式进行数据的存储，通过raft 进行强一致，多个副本中只有一个leader 其他节点为follower，其中leader 和follower值不固定的，在leader失效后，会选择follower通过算法变为leader的角色变换。
Raft 本身是支持一份数据的强一致的多副本，分布式数据如何切片，如何将不同的切片放到不同的位置上，这就需要一个分片的算法，基于hash的分片，或者基于range 划分，但由于数据库在查询中会涉及到一段连续值的查询的可能，则利用range分片比较合理。将存储KEY 的空间进行切分，主要根据KEY VALUE存储的阈值来进行，默认96MB进行数据的切分。
下图是一个多节点中某个节点 region 从节点 1 到 节点4的过程
则问题是在数据的迁移中，谁主导了整体迁移的操控，Placement Driver集群主导了。
具体可以看上图，另外在事务模型中，PD 的leader 会根据时间算法提供时间戳，作为事务的标签，整体以去中心化为设计理念。在TIDB 中3.0前以乐观锁为锁的设计，在数据事务处理中并不会上锁，而是在提交的过程中上锁。3.0提供了悲观锁，类似传统数据库的锁设计。
3 TIDB SQL 引擎
下图是一张TIDB SQL 层的整体的图形。
整体的SQL 处理流程， 如果是计算 COUNT ， 则TIDB PD获知这些数据在那个 region 中，region 根据where 条件，将符合的条件的数据进行累加和，最终每个region将自己的累加和汇总到 TIDB SERVER ,在进行聚合SUM。
4 DDL 在线修改，TIDB 根据 f1-schema-change 的思想来设计整体DDL 操作。具体可以参考下面的文档，总结出几句话
1 给与修改DDL 操作一个时间范围
2 在DDL 操作中，每个region都会提供两种状态,可以删除和可写状态
3 租约的概念，在系统中设定的租约到期后，需要重载SCHEMA
http://disksing.com/understanding-f1-schema-change/
