TIDB学习笔记-体系架构

Posted 2023-03-30 404Rapper..

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 使用教程，TiDB SQLConnector API架构体系…你一定不能错过

在业务爆发式增长的过程中，基于 MySQL 构建的传统关系型数据库服务，已逐渐难以满足复杂的数据库存储、管理与运维，分布式数据库应运而生。

TiDB 作为一款开源的分布式关系型数据库，能够实现灵活的扩缩容、支持多点写入、企业级高可用，同时协议兼容 MySQL、对业务又能像单机 MySQL 一样使用，已经应用在了知乎、b 站、北京银行、平安科技等众多企业的业务架构中。

根据京东物流某系统的测试使用情况，从 MySQL 迁移到 TiDB 后，通过总共数百个指标的检测，发现整体性能实现了 8 倍提升。

对于应用开发者而言，TiDB 和 MySQL 的语法高度兼容，上手成本很低。但是如何最大化 TiDB 的架构优势，如何基于 TiDB 进行产品设计，探索最佳实践，实现降本增效的目的？

TiDB 的文档和课程十分丰富，有面向内核开发的 Talent Plan 课程（https://tidb.io/talent-plan，复制链接至浏览器打开）和被誉为 TiDB 二十四章经的源码阅读系列，也有面向 DBA 的系统管理课程，还有面向所有对技术感兴趣的小白同学的 101 课程（https://learn.pingcap.com/learner/course/6，复制链接至浏览器打开）。而面向 应用开发者 的课程一直是我们未曾涉及的领域。「TiDB SQL for Developers」正是 PingCAP Education 为了填补这个空白而策划的系列课程。

点击下方链接，立即开启你的 TiDB 应用开发学习之旅

这门面向应用开发者的 TiDB 使用教程，TiDB SQL、Connector API、架构体系…你一定不能错过！ (qq.com)

「TiDB SQL fo Developers」全系列课程注重实际操作技能，为后端开发者或意向成为后端开发的学习者详细介绍如何在 TiDB 上使用 SQL 语言、以及利用 Connectors API 对数据进行各种操作。整个课程家族分为五个模块，并根据大家的知识领域和学习目标制定了不同的学习路径。

《TiDB SQL for Developers》课程家族介绍

作为「TiDB SQL fo Developers」课程家族的首发课程，《201.1 TiDB 集群的架构与特点》现已免费开放学习，你可以在 90 分钟内快速了解：

• TiDB 数据库三大核心组件（PD、TiKV、TiDB）的作用；
• Raft 算法对 TiKV 和 PD 组件的重要性；
• 行记录转化为 TiKV 键值对的原理以及 MVCC 的重要性；
• TiDB 的分布式 SQL；
• TiDB 与传统非分布式数据库相比的特点