TIDB初识
作者：互联网
TIDB初识
整体架构图
负载均衡层
这一次层其实属于非TIDB的架构层，不过为了方便整体性的理解，这里简单叙述下.由于TIDB SERVER层是一个无状态的集群，所以外部客户端访问的时候，需要通过一个负载路由到某一台TIDB SERVER.
TIDB SERVER层
这一层通过mysql原生的协议与应用applocation层交互。接收来自应用层的sql请求。
接收到SQL请求后，会在这一层通过词法分析、语法分析，形成语法数，以及执行计划等。然后将执行计划拆分成多个任务，向TIKV请求数据。拆分前，会向PD获取TIKV集群的数据库元信息(database/tabl 等定义信息)，以及数据的region信息，根据这些内容，向不同的TIKV节点发送数据请求。如果有事务，需要向PD集群申请事务ID(一个long类型时间戳)。
向下，会与TIKV交互，获取数据，以及将数据做一些排序，合并，计算等数据操作，然后返回客户端。
TIKV层
真正的数据存储层(数据引擎)，目前使用的是RocksDB.这是一个KV结构存储的超级大的map.最小的存储结构为region，每个region是一个左闭右开的区间,以key(默认主键，否则默认生成一个long的rowid主键)排序的区间.例如表t1,
CREATE TABLE t1 {
id BIGINT PRIMARY KEY,
name VARCHAR(1024),
age BIGINT,
content BLOB,
UNIQUE(name),
INDEX(age),
}
(表ID全局唯一,索引ID全局唯一)
里面有数据2条:(1, “a”, 10, “hello”),(2, “b”, 12, “world”).
那么数据文件region里面的内容如下:
t_11_1 -> (1, “a”, 10, “hello”)
t_11_2 -> (2, “b”, 12, “world”)
其中t表示是表+11是表ID+主键的value
索引name的文件内容如下(唯一索引):
i_12_a -> 1
i_12_b -> 2
其中i表示索引+12索引编号ID+索引列value
索引age的文件内容如下(非唯一索引):
i_13_10_1 -> nil
i_13_12_2 -> nil
其中i表示索引+13索引编号ID+索引列value+主键value
分布式数据一致(主从同步)
保持在主从region数据的一致是通过raft协议实现。
TiKV 使用 Raft 一致性算法来保证数据的安全，默认提供的是三个副本支持，这三个副本形成了一个 Raft Group。当 Client 需要写入某个数据的时候，Client 会将操作发送给 Raft Leader，这个在 TiKV 里面我们叫做 Propose，Leader 会将操作编码成一个 entry，写入到自己的 Raft Log 里面，这个我们叫做 Append。Leader 也会通过 Raft 算法将 entry 复制到其他的 Follower 上面，这个我们叫做 Replicate。Follower 收到这个 entry 之后也会同样进行 Append 操作，顺带告诉 Leader Append 成功。当 Leader 发现这个 entry 已经被大多数节点 Append，就认为这个 entry 已经是 Committed 的了，然后就可以将 entry 里面的操作解码出来，执行并且应用到状态机里面，这个我们叫做 Apply。
分布式的事务一致(不同region 数据操作同步)
实现分布式事务的一致是通过Percolator，一个2PC方式实现的.
首先，Percolator 需要一个服务 timestamp oracle (TSO) 来分配全局的 timestamp，这个 timestamp 是按照时间单调递增的，而且全局唯一。任何事务在开始的时候会先拿一个 start timestamp (startTS)，然后在事务提交的时候会拿一个 commit timestamp (commitTS)。
Percolator 提供三个 column family (CF)，Lock，Data 和 Write，当写入一个 key-value 的时候，会将这个 key 的 lock 放到 Lock CF 里面，会将实际的 value 放到 Data CF 里面，如果这次写入 commit 成功，则会将对应的 commit 信息放到入 Write CF 里面。
PD集群
该集群主要是为了感知TIKV的集群信息，存储信息，以及故障状态，并为优化调整集群而生成一些调度任务，并执行.
- 信息收集
TiKV 节点周期性地向 PD 上报 StoreHeartbeat 和 RegionHeartbeat 两种心跳消息。其中 StoreHeartbeat 包含了 Store 的基本信息，容量，剩余空间，读写流量等数据，RegionHeartbeat 包含了 Region 的范围，副本分布，副本状态，数据量，读写流量等数据。PD 将这些信息梳理并转存供调度来决策。
- 生成调度
不同的调度器从自身的逻辑和需求出发，考虑各种限制和约束后生成待执行的 Operator。这里所说的限制和约束包括但不限于：
不往断连中、下线中、繁忙、空间不足、在大量收发 snapshot 等各种异常状态的 Store 添加副本
Balance 时不选择状态异常的 Region
不尝试把 Leader 转移给 Pending Peer
不尝试直接移除 Leader
不破坏 Region 各种副本的物理隔离
不破坏 Label property 等约束
- 执行调度
生成的 Operator 不会立即开始执行，而是首先会进入一个由 OperatorController 管理的一个等待队列。OperatorController 会根据配置以一定的并发从等待队列中取出 Operator 进行执行，执行的过程就是依次把每个 Operator Step 下发给对应 Region 的 Leader。
最终 Operator 执行完毕会被标记为 finish 状态或者超时被标记为 timeout，并从执行列表中移除。
标签：region,TIKV,索引,初识,value,TIDB,Leader 来源： https://blog.csdn.net/zhongxuancnc/article/details/115360947