dnuiking的博客

T0 时刻从客户端写入两行数据分别写入到了两个region，并且产生raft log此时TiFlash还没有TiKV的这两行数据此时TiFlash同步了key=1 value=100的数据还没有同步 key=999 value=7的数据读取TiFlash中的key=1和key=999又进行了一次写入 key=1 value=200此时raftlog idx=122确认TIKV的raft log idx号并且记录在TiFlash此时，idx=31 从TIKV记录的日志。

TiDB的MPP架构充分利用了TiFlash并行计算的功能， 当一个复杂的SQL语句过来的时候（能够使用MPP），先利用表连接的条件把连接条件Hash值相同的数据放到一个节点上，防止网络交换严重，处理了过滤条件后，如有聚合条件，再利用聚合条件的字段进行数据交换，把聚合条件字段hash值相同的数据放到同一个数据节点中，最后每个TiFlash把计算好的数据返回给TiDB Server。

首先TSO的分配涉及到TiDB Server 和 PD组件但如果此时TSO有一百个请求，PD Client不会 一次次的请求PD，则PD Client会把这一百个请求变成一个批处理请求发送给PD相关优化：PD leader解决性能问题的方法PD 的高可用如果此时TiDB Server请求的是704此时PD ledaer宕机，则切换leader PD，开始一次新的3s计时（即TiDBServer 请求的TSO会有断层，代表此时PD leader 宕机了） ，即保证不了连续性。

leader是集群中领导者，所有的读写都是走leader，follower副本不参加读写，leader会周期性的向follower发出心跳，同时也会把自己的日志同步给follower。follower不参与读写，只会对其它服务做出相应，并同步leader的日志。如果长时间收不到leader的心跳信息，这时候follower会把自己的角色变为condidate（候选者），并发起投票。其中一个region 及其两个副本 构成一个raft group ，多个raft group 构成了multi raft。

读操作先从Write 列簇中读取最近一次提交信息，找到最近一次提交信息的事务开始时间，直接去Default中去读写操作也是先从Write 列簇中读取最近一次提交信息，找到最近一次提交信息的事务开始时间，之后要去Lock列簇中查看写是否被阻塞。如果没阻塞才可以去Default列簇中去读

下图总结了RocksDB 写操作的流程。可以看出LSM Tree对写操作进行了很大力度的优化，所以LSMTree对写很友好，但对读不那么友好，如果数据在mem Table中还好说，但如果不在Mem Tble中 下一步应该去immutable 中去中，如果immutable中没有 又会到磁盘中去找。

TiDB Server 架构。

首先TiDB深度兼容MySQL 5.7。