TIDB学习笔记(二)-体系架构

TIDB的优势:分布式,高度兼容MySQL,高可用,支持ACID事务(事务模型:Percolator),丰富的工具链生态

一、TiDB
SQL层,解析SQL,将数据读取请求发给TiKV/TiFlash

功能:

  1. 处理客户端的连接
  2. SQL语句的解析和编译
  3. 关系型数据与KV的转化
  4. SQL语句的执行
  5. 在线DDL的执行
  6. GC
  • TiDB中的KV模块处理简单的等值查询,DistSQL处理较复杂的查询,将其进行拆分为简单查询。
  • 在线DDL,不阻塞读写。同一时刻只能进行一个job,在TiKV中排队处理。TiDB轮流作为owner去调度job。
  • GC回收MVCC产生的过期的历史数据。GC lifetime默认10min

TiDB缓存组成:SQL结果,线程缓存,元数据,统计信息

缓存管理:tidb_mem_quota_query,oom-action
二、PD
集群的大脑。元信息管理模块,负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构,分配分布式事务ID,根据 TiKV 节点实时上报的数据分布状态,下发数据调度命令给具体的 TiKV 节点

功能:

  1. 整个集群TiKV的元数据存储
  2. 分配全局ID和事务ID
  3. 生成全局时间戳TSO
  4. 收集集群信息进行调度
  5. 提供TiDB Dashboard服务
  6. 提供label功能支持高可用

TSO

int(64)   TSO=physical time + logical time

获取流程:TSO请求者 -> PD Client ->PD leader ->PD Client -> TSO请求者

                                           PD -> PD Client -> TSO请求者

PD每次分配给TiDB3秒内的TSO。如果中途PD leader宕机,则TSO将继续增加,可能出现TSO的不连续现象,但并不影响高可用。

调度:信息收集->生成调度->执行调度

生成调度:Balance (leader,region,hot region)

                  集群拓扑

                  缩容

                  故障恢复

                  Region merge

label:为每个TiKV实例做的标签,标识其所在位置   zone  rack  host

三、TiKV
存储数据,分布式提供事务的KV存储引擎
存储数据的基本单位是Region,每个TiKV会负责多个Region,默认SI(Snapshot Isolation)隔离级别

TiKV通过协处理器Corprocessor可以为 TiDB 分担一部分计算:TiDB 会将可以由存储层分担的计算下推
以 Region 为单位,将数据分散在集群中所有的节点上,并且尽量保证每个节点上服务的 Region 数量差不多。
以 Region 为单位做 Raft 的复制和成员管理。

功能:

  1. 数据持久化
  2. 分布式事务支持
  3. 副本的强一致性和高可用性
  4. MVCC
  5. Coprocessor(算子下推)

四、TiFlash

功能:

  1. 列式存储提高分析查询效率
  2. 支持强一致性和实时性
  3. 业务分离
  4. 智能选择


五、RocksDB LSM-Tree架构引擎,单机持久化KV存储引擎,针对Flash存储进行优化,延迟极小。

  • 高性能的Key-Value数据库
  • 完善的持久化机制
  • 良好的支持范围查询
  • 存储中小键值优化
  • 性能随CPU数量线性提升,对多核系统友好

每个TiKV中有两个RocksDB,一个raftdb存储Raft日志,一个kvdb存储数据和MVCC信息

写操作过程:写请求->磁盘记录日志(WAL,防止数据丢失)->内存MemTable->immutable MemTable ->刷到磁盘(磁盘中会对Level进行合并,随机写变为顺序写)

写操作为一次磁盘IO,一次内存IO。写操作访问内存MemTable即可(简单理解为写入的操作一直在追加),读操作要访问内存...->磁盘level...

Column Families 列簇,每个CF中可以有一类或多类键值对,数据分片功能, 各自使用各自部分的内存磁盘,共用WAL日志文件。每个RocksDB可以有多个CF,每个TiKV中有4个Column Family,每个CF中的最多有5个MemTable存在,MemTable的大小限制是128MB。

六、Raft协议
重要功能:Leader(主副本)选举,成员变更,日志复制

日志复制propose 写入数据时发指令给leader后,写入raft log

                  append leader将日志进行持久化写入到RocksDB

                  replicate follower收到指令后后写入写入到RocksDB

                        append

                  committed 多数节点(超过一半以上)持久化完成后发送指令给leader,只是raft log的持久化

                  apply  真正的提交,rocksdb raft -> rocksdb kv ,写入的数据可在RocksDB中查询到

至此,一个写入的操作才算commit

Leader选举: follower等待leader  election timeout,这个时间后没有响应,此follower将发起选举,term升级,作为candidate,发起投票后成为leader(超过一半的投票)

                        leader宕机后,follower等待heartbeat time interval ,没有响应后,此follower将发起选举,term升级,作为candidate,发起投票后成为leader(超过一半的投票)

                        多节点等待leader超时后,同时发起选举,生成随机等待的响应时间,可快速选举出leader

raft-election-timeout-ticks >= raft-heartbeat-ticks

七、Region
将KV的空间分成若干段,Region为其中一段,是一个左闭右开的区间,存储数据的大小不超过96MB

当Region的大小超过144MB(默认)时,将分裂。

八、调度

TiKV->Region->Replica
每个Region有多个副本,这些副本分布在不同的TiKV节点上。Leader负责读写,Follower负责同步Leader同步过来的Raft log
分布式高可用存储系统需满足:

  1. 副本数量不能多也不能少
  2. 副本需要根据拓扑结构分布在不同属性的机器上
  3. 节点宕机或异常能够自动合理快速地进行容灾

良好的分布式系统需满足:

  1. 维持整个集群的 Leader 分布均匀
  2. 维持每个节点的储存容量均匀
  3. 维持访问热点分布均匀
  4. 控制负载均衡的速度,避免影响在线服务
  5. 管理节点状态,包括手动上线/下线节点

调度操作:增加、删除副本,将 Leader 角色在一个 Raft Group 的不同副本之间 transfer
信息收集:

  1. Store Headtbeat   每个 TiKV 节点会定期向 PD 汇报节点的状态信息 
  2. Region Heartbeat  每个 Raft Group 的 Leader 会定期向 PD 汇报 Region 的状态信息

调度策略:

  1. 一个 Region 的副本数量正确
  2. 一个 Raft Group 中的多个副本不在同一个位置
  3. 副本在 Store 之间的分布均匀分配
  4. Leader 数量在 Store 之间均匀分配
  5. 访问热点数量在 Store 之间均匀分配
  6. 各个 Store 的存储空间占用大致相等
  7. 控制调度速度,避免影响在线服务

九、分布式事务

提交分两阶段:1.prewrite:修改数据和锁信息   2.commit  时间戳从PD获取

悲观锁。只为事务中修改的第一行加锁

TiKV节点中有三个列簇:Default,Lock,Write

        write列存储数据长度小于255字节

        default列存储数据长度大于255字节

一个事务中修改的如果数据在不同的TiKV节点上,事务中修改的第一行加主锁,后面的行表明主锁所在的TiKV节点。事务执行中途宕机后进行恢复,后面的修改数据的操作查询主锁的状况。

十、数据的写入

TiDB->raftstore pool ->rocksdb raft

                                 ->apply pool ->rocksdb kv

十一、数据的读取 ReadIndex

Lease Read 接收到读请求后,leader会给follower发心跳确认自己是否是leader,在election timeout时间限制内都不会发生重新选举

ReadIndex:读取的点在想读的数据之后,这样保证一定可以读到想读的数据(此处暂不提MVCC机制)

Follower Read:等待follower上的提交点提交后,和ReadIndex读取方式类似。从follower读取可能更快,这取决于apply的速度。

十二、SQL语句执行流程

DML:读请求->Protocol Layer ->PD(TSO)->Parse->Compile->Execute->TiKV返回结果

           写请求->Protocol Layer ->PD(TSO)->Parse->Compile->Execute->TiKV->memBuffer->Transaction(1.两阶段提交  2.从PD获得TSO)->TiKV

编译部分:对于点查可直接找出数据后修改。非点查会进行一系列解析优化

DDL:online DDL,TiKV存在三种队列 job queue,add index queue ,history queue

           每个TiDB节点都可以接收DDL请求,接收后将其存放在job queue中,然后由具有owner角色的worker进行执行(owner会定期进行选举),执行后放入到history queue。

你可能感兴趣的:(TiDB,分布式,数据库)