最近TIDB 开放了相关的初级课程，目前最火热的分布式数据库，那是的深入一下，最近一段时间都会围绕TIDB 的课程学习来写一写相关的总结和体会。
一款数据库个人认为主要的点有两个， 1 存储 2 计算，这是任何数据库都离不开了，作为数据库如果是单点的情况下，则计算和存储都会受到单点的限制，那么这就出现了瓶颈， 而分布式数据库的出现就是要解决这个问题， 无论是存储还是计算，都是需要 scale out 的，也就是扩展。
说到扩展，那么当然你可以用昂贵的硬件来做扩展，当然你也你可以用便宜的X86来进行扩展。
这里会涉及两个需求， 1 必须完成 2 锦上添花
1 扩展性
2 强一致和高可用， 包含数据恢复时间RTO 和 数据丢失可能性 RPO
3 标准SQL 与 ACID 事务
4 云原生
5 HTAP
6 兼容主流生态协议
——————————————————————————————
在上面的这些需求里面包含了如下技术栈领域常见的基础因素
1 数据模型
2 数据存储与检索结构
3 数据格式
4 存储引起
5 复制协议
6 分布式事务模型
7 数据架构
8 优化器算法
9 执行引擎
10 计算引擎
那么到底分布式数据库中计算与存储的设计开始分离了， 这里主要的原因是硬件的变化，在早先的网络基础上，无法做到通过网络快速进行数据的快速的传输，所以当时的主机的形式大多是单节点结构，而随着后面的硬件的演变，给分布式数据库创造了新的可能性，原先的数据库机构很难进行随意的扩展，主要是单个节点赋予了太多的功能，导致扩展方面困难，计算和存储节点在一起。
而随着云原生和硬件技术的发展， 计算与存储分离的设计让扩展变得简单，每个机器的功能定位变得单纯了。TIDB 是在2015年开始的，主要的思想就是扩展。
上图是一个TIDB 的结构，主要有 TIDB 数据计算层， TIKV 数据存储层， 与PD Placement driver 调度节点组成，支持主流的 MYSQL 协议，作为标准化的输入语言。
在TIKV 层完成了数据存储，事务支持， 多版本控制，分布式协议RAFT，以及数据存储 ROCKSDB 的集成。
TIDB 作为计算节点，支持SQL ，SQL 解析，执行计划的生成，选择合适的执行计划等功能 ，目前支持MYSQL 5.7 的语法和 8.0部分语法。
而PD 作为联系无状态计算 和 分布式存储测中间点存在。主要的功能是数据的授时和调度TIKV 分布式序列号分发，节点的存储情况和工作情况，在根据数据库存储设计的规则，将数据进行调度存储的分布。
那么下面我就看看 TIKV 是怎么工作的， TIKV 本身是TIDB 的存储引擎，而TIKV 主要的工作职能有
1 更细粒度的弹性扩容
2 高并发读写
3 数据的持久性完成
4 数据多副本的特性
5 分布式事务支持
TIKV是TIDB 的数据存储引擎，而数据存储引擎中核心的要解决的问题是数据的存储和数据的提取， 在数据存储结构中，要提到的就是数据的组织结构，数据的组织结构中，目前有两种数据的组织结构， BTREE 和 LSM TREE ，相对于数据原理，单节点的数据结构组织大多使用了BTREE的数据组织方式，例如索引，而对于分布式数据存储，尤其需要数据进行分片的场景，BTREE的组织形式是否合适就需要讨论了。尤其是数据的写入的成本，顺序写或随机写，随机写一般是需要通过日志和数据两次落盘的方式， 而LSM tree 是支持批量吸入，并且不需要日志首次的落盘。
而数据副本的写入首先是需要进行副本的选择，通过RAFT 协议来进行数据的写入和副本的选择以及LEADER 的选择。
副本的选择完毕后，并非就结束了，更重要的一点关于数据的如何在副本中进行更细粒度的存放是一个要解决的问题，否则TIDB 就会和普通的MYSQL分片的中间件没有什么区别了。
关于数据如何耕细粒度的分片，这里TIDB选择了自动动态的range 分片的范式
range 分片的优点和缺点也很明确，这里需要根据业务的特性来进行选择，如果选择了HASH 分片将数据打散的情况，在OLTP或OLAP的业务中，会存在范围查询的问题，而范围查询中数据的集中度越高越好，而不是越分散越好，而数据集中度高了，缺点就是热点读的问题，数据不散开读取数据的集中度会增高，并且最后的数据分片可能是热点读的重点，会对数据的集中并发热点读产生性能的瓶颈。
通过range 分片的好处在TIKV存储中，体现的很明显，这里TIKV是通过KEY :VALUE的存储数据，而查找数据也是通过范围方式的查找，一个REGION的大小在96MB，而我们的数据随着存储的量越来越大会分裂成更多的Region， REGION 则是TIKV中数据存储的单位。
PD 中记录了数据在整体TIKV的分布情况，并且进行数据的REGION进行调度和平衡，平均使用NODE。
TIKV 中MVCC 是在数据的存储中通过KEY:VALUE 版本号的方式来进行多版本控制。而默认的隔离级别是snapshot lsolation (具体什么是snapshot lsolation 参见周一的 6种隔离级别中的snapshot lsolation 文字)
与传统的数据库不同，TIDB 并么有将数据的锁信息存储在行中，如PG 或 MYSQL ，（事务号）， 而是将锁存储在TIKV划分的单独的区域中，名字为CF LOCK ，这样有利与分布式去中心话的形成， 通过通过PD 来进行全局授时服务，这样的优点是，分布式的所有事务都时序化了，不会存在冲突，并且在乐观事务模型中，最终如何判断哪些事务可以COMMIT 哪些不能，必须有一个时间的概念或事务的时间戳的概念。
TIDB 在3.0 后支持悲观锁，并且也支持高并发小SQL的异步操作。并且数据的计算单元也在TIKV中实现。（这里想问一个我问题，为什么 TIDB 后期也选择了悲观锁，而不是初期的乐观锁）
