印刻数据库

外观

TiDB 整体架构 ​

架构设计理念 ​

计算存储分离 ​

TiDB 采用计算存储分离的架构设计，将数据库的计算层和存储层完全分离：

  • 计算层：负责 SQL 解析、优化、执行等计算密集型操作
  • 存储层：负责数据的持久化存储、复制和高可用
  • 管理层：负责集群调度、元数据管理和资源分配

这种设计带来的优势：

  • 计算和存储可以独立扩展，提高资源利用率
  • 支持多种存储引擎，适应不同场景需求
  • 便于实现混合部署，如计算层部署在云主机，存储层使用对象存储
  • 简化集群管理，便于升级和维护

水平扩展 ​

TiDB 采用水平扩展架构，通过增加节点数量来提升系统容量和性能：

  • 计算层（TiDB Server）：无状态设计，可线性扩展
  • 存储层（TiKV Server）：数据自动分片，支持 PB 级存储
  • 管理层（PD Server）：采用 Raft 协议，支持高可用

高可用性 ​

TiDB 架构设计保证了系统的高可用性：

  • 所有组件均无单点故障
  • 数据多副本存储（默认 3 副本）
  • 基于 Raft 协议实现数据一致性和自动故障转移
  • 支持跨 AZ/Region 部署，提高容灾能力

强一致性 ​

TiDB 保证数据的强一致性：

  • 基于 Raft 协议实现数据复制和一致性
  • 分布式事务支持完整的 ACID 特性
  • 全局唯一时间戳生成器（TSO）保证事务的外部一致性

核心组件 ​

1. TiDB Server ​

角色：SQL 计算层，负责处理客户端请求

主要功能：

  • 接收和处理客户端连接
  • SQL 解析和语法检查
  • 查询优化，生成执行计划
  • 分布式执行计划调度
  • 结果集聚合和返回
  • 事务管理，支持 ACID 事务

特点：

  • 无状态设计，可水平扩展
  • 兼容 MySQL 5.7/8.0 协议
  • 支持分布式事务
  • 支持并行查询执行

部署建议：

  • 建议部署 2-3 个节点，满足高可用性
  • 根据业务负载水平扩展
  • 部署在计算资源充足的服务器上

2. TiKV Server ​

角色：分布式键值存储，负责数据持久化存储

主要功能：

  • 数据存储和持久化
  • 数据复制和一致性维护（基于 Raft 协议）
  • 分布式事务处理
  • 数据分片管理（Region）
  • 热点数据处理

特点：

  • 基于 RocksDB 存储引擎
  • 数据按 Range 自动分片为 Region
  • 支持水平扩展，PB 级存储容量
  • 强一致性保证

部署建议：

  • 建议部署奇数个节点（3、5 等），满足 Raft 协议要求
  • 每个节点配备高速 SSD
  • 部署在存储性能优异的服务器上

3. PD (Placement Driver) ​

角色：集群管理中心，负责元数据管理和调度

主要功能：

  • 集群元数据管理
  • Region 分布和调度
  • 节点状态监控
  • 全局唯一时间戳生成（TSO）
  • 数据均衡和热点调度

特点：

  • 基于 Raft 协议实现高可用
  • 无状态设计，可水平扩展
  • 智能调度算法，优化集群性能

部署建议：

  • 建议部署 3 个节点，满足高可用性
  • 部署在低延迟、高可靠性的服务器上
  • 与 TiKV 节点分开部署

4. TiFlash ​

角色：列式存储引擎，支持 HTAP 场景

主要功能：

  • 列式数据存储
  • 实时数据同步（从 TiKV）
  • MPP 分布式查询执行
  • 向量计算加速

特点：

  • 与 TiKV 实时同步数据
  • 支持 ACID 事务
  • 适合 OLAP 查询场景
  • 可与 TiKV 共存，实现 HTAP

部署建议：

  • 建议部署在分析型服务器上
  • 每个节点配备大容量 SSD 或 HDD
  • 根据分析负载水平扩展

5. TiCDC ​

角色：变更数据捕获，支持实时数据同步

主要功能：

  • 实时捕获 TiKV 数据变更
  • 支持多种下游系统（MySQL、Kafka、S3 等）
  • 保证数据一致性和顺序性
  • 支持跨集群数据同步

特点：

  • 无侵入式设计，不影响 TiKV 性能
  • 高吞吐、低延迟
  • 支持水平扩展

部署建议：

  • 建议部署 2-3 个节点，满足高可用性
  • 部署在网络带宽充足的服务器上

数据组织方式 ​

Region 机制 ​

TiKV 将数据按照主键范围自动分片为 Region，每个 Region 是数据管理的基本单位：

  • 默认大小：96MB
  • 自动拆分：Region 大小超过阈值时自动拆分
  • 自动合并：相邻小 Region 自动合并
  • 多副本存储：每个 Region 存储 3 个副本（默认）
  • Raft 组：每个 Region 的副本组成一个 Raft 组，保证数据一致性

数据分布 ​

  • Range 分片：数据按照主键范围分配到不同 Region
  • 副本分布策略：副本分布在不同节点，优先跨 AZ/Region 分布
  • 数据均衡：PD 自动调度 Region，平衡节点负载
  • 热点调度：PD 自动识别和处理热点 Region，分散热点负载

元数据管理 ​

  • Region 元数据：存储 Region 的范围、副本位置等信息
  • Store 元数据：存储节点的状态、资源使用情况等信息
  • Cluster 元数据：存储集群的整体配置和状态
  • 元数据存储：元数据存储在 PD 中，基于 Raft 协议保证高可用

数据流转过程 ​

1. 查询执行流程 ​

客户端 → TiDB Server → 解析 SQL → 查询优化 → 生成执行计划 → 分发执行任务 →
TiKV Server 1 → TiKV Server 2 → ... → 结果集聚合 → TiDB Server → 客户端

详细步骤：

  1. 客户端向 TiDB Server 发送 SQL 请求
  2. TiDB Server 解析 SQL，生成逻辑执行计划
  3. 查询优化器优化执行计划，生成物理执行计划
  4. TiDB Server 将执行计划分发到相关的 TiKV Server 节点
  5. TiKV Server 执行本地数据扫描和计算
  6. TiDB Server 收集和聚合各个 TiKV Server 返回的结果
  7. TiDB Server 将最终结果返回给客户端

2. 写入执行流程 ​

客户端 → TiDB Server → 解析 SQL → 事务开始 → 写入数据 → 事务提交 →
TiDB Server → 二阶段提交 → TiKV Server 1 (Leader) → Raft 复制 → TiKV Server 2, 3 (Follower) →
提交确认 → TiDB Server → 客户端

详细步骤：

  1. 客户端向 TiDB Server 发送写入请求
  2. TiDB Server 解析 SQL，开始事务
  3. TiDB Server 向 PD 请求全局唯一时间戳（TSO）
  4. TiDB Server 向相关 TiKV Server 发送写入请求
  5. TiKV Server Leader 写入数据，并通过 Raft 协议复制到 Follower 节点
  6. 所有副本确认写入成功后，TiKV Server Leader 返回确认信息
  7. TiDB Server 完成事务提交，返回结果给客户端

3. 事务处理流程 ​

TiDB 支持两种事务模式：

乐观事务 ​

  • 默认事务模式
  • 事务提交前不进行锁检查
  • 提交时检查冲突，冲突则重试
  • 适合低冲突场景，并发性能高

悲观事务 ​

  • 显式加锁，避免冲突
  • 适合高冲突场景
  • 减少事务重试，提高成功率
  • 语法兼容 MySQL 悲观锁

架构优势 ​

1. 水平扩展能力 ​

  • 计算层扩展：通过增加 TiDB Server 节点提升并发查询能力
  • 存储层扩展：通过增加 TiKV Server 节点提升存储容量和写入性能
  • 在线扩容：支持在线扩容，无需停机
  • 弹性伸缩：根据业务负载动态调整集群规模

2. 高可用性 ​

  • 无单点故障：所有组件均采用高可用设计
  • 自动故障转移：节点故障时自动选举新 Leader，RTO < 30 秒
  • 多副本存储：数据默认存储 3 个副本，保证数据安全性
  • 跨 AZ/Region 部署：支持跨可用区或跨地域部署，提高容灾能力

3. 强一致性 ​

  • Raft 协议：保证数据副本之间的强一致性
  • 分布式事务：支持完整的 ACID 事务
  • 外部一致性：基于 TSO 实现事务的全局顺序
  • 线性一致性读：保证读取最新版本的数据

4. MySQL 兼容性 ​

  • 协议兼容：完全兼容 MySQL 5.7/8.0 协议
  • 语法兼容：支持大部分 MySQL 语法和函数
  • 工具兼容：支持 MySQL 生态工具，如 mysqldump、MySQL Workbench 等
  • 应用迁移：现有 MySQL 应用无需修改或只需少量修改即可迁移到 TiDB

5. HTAP 能力 ​

  • TiKV + TiFlash：行存（OLTP）和列存（OLAP）结合
  • 实时数据同步：TiFlash 与 TiKV 实时同步数据
  • 无需 ETL：分析查询直接访问实时数据，延迟低
  • 智能查询路由：优化器自动选择最优执行引擎

6. 云原生设计 ​

  • 容器化支持：支持 Docker 容器化部署
  • Kubernetes 原生：提供 TiDB Operator，支持在 Kubernetes 上部署和管理
  • 声明式配置：通过 YAML 文件定义集群状态
  • 自动运维：支持自动扩缩容、升级、备份等操作

部署模式 ​

1. 单机测试部署 ​

适用场景：开发和测试环境

部署特点：

  • 所有组件部署在同一台机器上
  • 资源消耗低，适合开发测试
  • 不保证高可用性

部署命令：

bash
tiup playground

2. 最小生产部署 ​

适用场景：小型生产环境，低并发需求

部署架构：

  • TiDB Server：2 个节点
  • TiKV Server：3 个节点（默认 3 副本）
  • PD Server：3 个节点
  • Monitor：1 个节点（Prometheus + Grafana）

资源要求：

  • 每个节点至少 8C 16GB 内存
  • TiKV 节点配备 SSD 存储

3. 标准生产部署 ​

适用场景：中大型生产环境，高并发需求

部署架构：

  • TiDB Server：3-5 个节点
  • TiKV Server：5-9 个节点
  • PD Server：3 个节点
  • TiFlash：2-3 个节点（如需 HTAP 能力）
  • TiCDC：2-3 个节点（如需实时数据同步）
  • Monitor：2 个节点（高可用部署）

资源要求：

  • TiDB Server：16C 32GB 内存起
  • TiKV Server：16C 64GB 内存起，配备高速 SSD
  • PD Server：8C 16GB 内存起
  • TiFlash：16C 64GB 内存起，配备大容量 SSD 或 HDD

4. 跨 AZ/Region 部署 ​

适用场景：对容灾要求高的生产环境

部署架构：

  • 跨 3 个 AZ 部署，每个 AZ 部署完整的组件
  • 数据副本分布在不同 AZ
  • 支持跨 AZ 故障转移

优势：

  • 提高容灾能力，单个 AZ 故障不影响业务
  • 降低网络延迟，就近访问数据
  • 符合多地多活架构设计

架构演进 ​

1. 早期架构 ​

  • 2015-2016 年：初始版本，核心组件包括 TiDB、TiKV、PD
  • 2017 年：1.0 版本发布，支持基本的分布式事务和水平扩展

2. 架构完善 ​

  • 2018 年：引入 TiFlash，支持 HTAP 混合负载
  • 2019 年：优化分布式事务，提升性能和稳定性
  • 2020 年：引入 TiCDC，支持实时数据同步

3. 云原生架构 ​

  • 2021 年：完善 TiDB Operator，支持 Kubernetes 原生部署
  • 2022 年：引入 PITR（Point-in-Time Recovery），支持精确到秒的恢复
  • 2023 年：优化查询优化器，提升复杂查询性能
  • 2024 年：进一步增强 HTAP 能力，优化云原生部署

4. 未来发展方向 ​

  • Serverless 架构：支持无服务器部署，自动扩缩容
  • AI 增强：引入 AI 优化查询计划和调度
  • 边缘计算：支持边缘计算场景
  • 多模态数据支持：支持结构化、半结构化和非结构化数据

与传统数据库架构对比 ​

与 MySQL 主从架构对比 ​

特性MySQL 主从TiDB
架构主从复制计算存储分离
扩展性垂直扩展水平扩展
高可用性依赖主从切换，RTO 分钟级自动故障转移，RTO < 30 秒
一致性最终一致性（主从）强一致性
存储容量受限于单节点无限扩展
并发能力受限于单节点线性扩展

与传统分布式数据库对比 ​

特性传统分布式数据库TiDB
扩展性手动分片，复杂度高自动分片，简单易用
SQL 兼容性部分兼容兼容 MySQL 5.7/8.0
事务支持部分支持或不支持分布式事务完整支持 ACID 分布式事务
运维复杂度高，需要手动管理分片低，自动管理分片和调度
云原生支持有限原生支持 Kubernetes 部署

常见问题（FAQ） ​

Q1: TiDB 架构中的计算存储分离有什么优势？ ​

A1: 计算存储分离的优势包括：

  • 计算和存储可以独立扩展，提高资源利用率
  • 支持多种存储引擎，适应不同场景需求
  • 便于实现混合部署，如计算层部署在云主机，存储层使用对象存储
  • 简化集群管理，便于升级和维护
  • 支持灵活的计费模式，如计算按 CPU 计费，存储按容量计费

Q2: TiDB 如何保证数据一致性？ ​

A2: TiDB 通过多种机制保证数据一致性：

  • 基于 Raft 协议实现数据复制和一致性
  • 分布式事务支持完整的 ACID 特性
  • 全局唯一时间戳生成器（TSO）保证事务的外部一致性
  • 支持线性一致性读，保证读取最新版本的数据

Q3: TiDB 支持哪些存储引擎？ ​

A3: TiDB 支持多种存储引擎：

  • TiKV：默认行存引擎，适合 OLTP 场景
  • TiFlash：列式存储引擎，适合 OLAP 场景
  • TiKV Raw：Raw KV 接口，适合需要直接操作键值的场景

Q4: TiDB 集群的规模可以扩展到多大？ ​

A4: TiDB 集群支持大规模扩展：

  • TiDB Server：支持数百个节点，提供高并发查询能力
  • TiKV Server：支持数百个节点，存储容量可达 PB 级
  • 单个集群可处理每秒数百万次查询和写入
  • 已在生产环境中验证支持数万亿条记录

Q5: TiDB 如何处理热点数据？ ​

A5: TiDB 提供多种机制处理热点数据：

  • 自动热点调度：PD 自动识别热点 Region，并将其分散到不同节点
  • 热点数据打散：支持将热点数据打散存储
  • 分区表：支持表分区，将数据分散到不同分区
  • 主键设计：建议使用分布式主键，如 UUID 或雪花算法，避免热点
  • 热点限流：支持热点限流，保护集群稳定

Q6: TiDB 适合哪些业务场景？ ​

A6: TiDB 适合多种业务场景：

  • 大规模 OLTP：高并发写入场景，如电商订单、金融交易
  • 实时数据分析：需要实时分析的场景，如实时报表、监控告警
  • 数据迁移整合：从 MySQL 迁移到分布式架构，多数据源整合
  • 云原生应用：容器化部署，Kubernetes 原生支持
  • HTAP 混合负载：同时需要事务处理和分析的场景

Q7: TiDB 如何实现高可用性？ ​

A7: TiDB 通过以下方式实现高可用性：

  • 所有组件均无单点故障
  • 数据多副本存储（默认 3 副本）
  • 基于 Raft 协议实现自动故障转移
  • 支持跨 AZ/Region 部署，提高容灾能力
  • 自动检测节点故障，快速恢复服务

Q8: TiDB 与 MySQL 的兼容性如何？ ​

A8: TiDB 与 MySQL 具有高度兼容性：

  • 兼容 MySQL 5.7/8.0 协议
  • 支持大部分 MySQL 语法和函数
  • 支持 MySQL 生态工具，如 mysqldump、MySQL Workbench 等
  • 支持主流 ORM 框架，如 Hibernate、MyBatis、Sequelize 等
  • 现有 MySQL 应用无需修改或只需少量修改即可迁移

Q9: TiDB 如何实现分布式事务？ ​

A9: TiDB 基于 Google Percolator 模型实现分布式事务：

  • 支持完整的 ACID 事务特性
  • 提供乐观锁和悲观锁两种事务模式
  • 基于二阶段提交（2PC）实现分布式事务提交
  • 全局唯一时间戳生成器（TSO）保证事务的外部一致性
  • 支持大事务优化，减少内存占用

Q10: TiDB 集群的部署和管理复杂吗？ ​

A10: TiDB 提供了完善的集群管理工具，简化部署和管理：

  • TiUP：官方推荐的集群管理工具，支持部署、升级、扩缩容等操作
  • TiDB Operator：Kubernetes 环境下的集群管理工具，支持声明式配置
  • 监控系统：集成 Prometheus 和 Grafana，提供丰富的监控指标和告警规则
  • 自动运维：支持自动扩缩容、自动故障转移、自动数据均衡等功能
  • 详细的官方文档和社区支持，降低学习成本