TiDB简介

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 协议和 MySQL 生态等重要特性。

TiDB目标
目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

五大核心特征

• 一键水平扩缩容
  得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

• 金融级高可用
  数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略，满足不同容灾级别的要求。

• 实时 HTAP
  提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

• 云原生的分布式数据库
  专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。

• 兼容 MySQL 协议和 MySQL 生态
  兼容 MySQL 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

官网：

https://docs.pingcap.com/zh/tidb/stable/overview

TiDB整体架构

与传统的单机数据库相比，TiDB 具有以下优势：

• 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容
• 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL
• 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明
• 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账
• 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景

在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。对应的架构图如下：

此图显示了TiDB的核心部分：PD cluster、TiDB cluster、Storage cluster。图中未显示的TiSpark是提供了OLAP的能力。

• TiDB Server：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。
  TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 TiProxy、LVS、HAProxy、ProxySQL 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。
  TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash），然后查询结果通过TiDB Server发送给客户端。
  TiDB Server也负责MVCC的老版本数据的回收。

• PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块（控制中枢），负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID(全局事务ID，以及其他的唯一ID)、产生全局TSO时间、控制Region在TiKV中的数据分布、Metadata也是由PD Server维护的。
  PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。
  此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。

• 存储节点

  • TiKV Server：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。（负责数据的持久化、MVCC、Coprocessor算子下推、事务、自身副本的高可用和强一致性。）
    存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。（也就是说，Region是TiDB分布式数据库分片的最小单元）。
    TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。
    TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。
    另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
  • TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

假设此时我们要执行一个SQL来存一条数据，那么过程大致如下：
1.首先应用的SQL负载均衡进入TiDB cluster，然后向PD cluster拿到TSO，即此次事务操作的时间戳；
2.然后由PD cluster决定Data location，即存在哪个TiKV、哪个Region单位上；
3.写入的TiKV是leader，然后leader同步其他TiKV节点，即follower；（TiDB也是用的raft算法，TiDB Server是无状态的，也不存数据；而TiKV Server和PD Server都是存在leader和follower的）；

官网：

https://docs.pingcap.com/zh/tidb/stable/tidb-architecture

核心模块小结

• TiDB Server：
  1.处理客户端连接（Protocol Layer）
  2.SQL语句的解析和编译
  3.关系型数据与KV的转化
  4.SQL语句的执行
  5.在线DDL的执行（不会阻塞读写 ）
  6.垃圾回收（GC模块）

• TiKV：
  1.数据持久化（选择了基于LSM-Tree结构的RocksDB引擎作为数据的永久存储引擎，而RocksDB引擎是通过WAL机制保证数据的不丢失及持久化）
  2.分布式事务支持（基于Percolator模型的事务两阶段提交的过程中，每个TiKV会单独分配存储锁的空间，即CFLock，是一个列簇）
  3.副本的强一致性和高可用性
  4.MVCC（多版本并发控制）
  5.Coprocessor（算子下推，减少了TiDB Server的计算成本）

• TiFlash：
  1.列式存储提高分析查询效率
  2.支持强一致性和实时性
  3.业务隔离（OLTP和OLAP业务两者不会互相干扰）
  4.智能选择（无论TiKV还是TiFlash，它们的SQL入口都是TiDB Server，TiDB中的优化器模型根据SQL特点及请求分类来决定是走TiKV还是TiFlash）

• PD Server：
  1.整个集群TiKV的元数据存储
  2.分配全局ID和事务ID
  3.生成全局时间戳TSO
  4.手机集群信息进行调度
  5.提供TiDB Dashboard服务