想必不少开发者都有过类似经历受制于传统数据库的局限处处碰壁。业务流量陡增分库分表改到崩溃离线分析查询半天出不来结果。再加上跨库事务、数据同步、弹性扩缩容等问题运维开发步步维艰。直到接触了 TiDB我才真正理解什么叫 “降维打击”。它作为一款兼容 MySQL 协议的 HTAP 数据库把 OLTP事务处理和 OLAP分析处理的能力捏合在了一起彻底解决了传统架构的痛点。今天我将从 6 个核心模块带你把 TiDB 从里到外扒得明明白白看完你也能给团队做架构选型一、TiDB 介绍与架构一张图看懂先从这张架构图说起1. 【应用接入】业务系统直接用 MySQL 协议连接 TiDB不用改代码无缝兼容。2. 【计算层TiDB 集群】多个无状态 TiDB 节点组成负责 SQL 解析、优化和执行可根据负载水平扩容。3. 【调度大脑PD 集群】整个分布式集群的 “中枢”负责分配时间戳、管理元数据、调度数据分片和负载均衡。4. 【存储层TiKV TiFlash】TiKV事务型 KV 存储用 Raft 协议保证强一致支撑 OLTP 业务。TiFlash列式存储专为 OLAP 分析查询优化实现事务与分析负载隔离。为什么这么设计传统数据库如 MySQL是“计算和存储绑死在一起”的单体架构。表一大、并发一高加机器都没用——因为数据都在一台机器上。TiDB 把计算、存储、调度彻底拆开每一层都可以独立扩容读并发高了加 TiDB 节点数据量大了加 TiKV 节点分析查询慢了加 TiFlash 节点这就是云原生数据库的核心能力按需伸缩独立扩展。要点TiDB 采用 Shared-Nothing 架构每个 TiKV 节点独立负责一部分数据Region通过 PD 统一调度实现真正的水平扩展。这一点和传统的 Shared-Disk 架构如 Oracle RAC有本质区别。二、TiDB 测试环境部署15分钟跑起来很多人觉得分布式数据库部署复杂其实 TiDB 在这方面做得相当友好。快速部署分为以下几步环境准备CentOS 7.x / Ubuntu 18.04下载 TiUP 集群管理工具编写拓扑配置文件一键部署验证集群状态极简部署实操# Step 1: 安装 TiUPcurl--protohttps--tlsv1.2-sSfhttps://tiup-mirrors.pingcap.com/install.sh|sh# Step 2: 启动本地测试集群单机模拟分布式tiup playground# 就这么简单一个命令本地跑起完整 TiDB 集群# 输出# CLUSTER START SUCCESSFULLY# TiDB: 127.0.0.1:4000 (MySQL兼容端口)# TiKV: 127.0.0.1:20160# PD: 127.0.0.1:2379# TiFlash: 127.0.0.1:3930就这么简单。一个命令本地完整集群全部跑起来。用任何 MySQL 客户端连接127.0.0.1:4000就能操作。生产环境部署拓扑建议组件最低节点数推荐节点数说明PD33 或 5奇数个Raft 选举需要TiDB12无状态按需扩TiKV33默认 3 副本最少 3 节点TiFlash01按需部署监控11Prometheus Grafana⚠️提醒生产环境 PD 和 TiKV 绝对不能部署在同一台机器上——PD 挂了整个集群就瘫痪了必须独立部署。三、TiKV 数据存储模块分布式 KV 的底层密码这是 TiDB 最核心、也最容易被忽视的一层。很多同学用 TiDB 写了一年 SQL都不知道底层数据是怎么存的。TiKV 是 TiDB 的存储核心也是很多架构师最关心的部分。它的设计细节直接决定了数据的可靠性和性能。3.1 核心存储引擎RocksDBTiKV 底层基于 RocksDB优化版的 LevelDB实现持久化存储支持高并发的读写和快速的范围查询完美适配了数据库的存储需求。3.2 数据分片Region 机制TiKV 把数据按连续的 Key 范围分成一个个 Region每个 Region 就像一个数据分片默认大小 96MB。比如笔记里的例子Region1 存储 Key1-Key3Region2 存储 Key4-Key6这种分片方式让数据天然具备水平扩展的能力数据量大了直接加 TiKV 节点就能扩容。3.3 强一致保证Raft 协议每个 Region 都会有 3 个副本也可配置 5 副本组成一个 Raft Group通过 Raft 协议实现数据的强一致复制。写操作会先写入 Raft 日志同步到多数副本后才会返回成功即使某个节点宕机其他副本也能接管服务保证数据不丢、服务不中断。Leader负责读写Follower同步复制要点Region 分裂是自动触发的——当 Region 大小超过阈值会自动一分为二PD 会重新调度副本分布。整个过程对业务完全透明。3.4 并发控制MVCC为了支持高并发读写TiKV 实现了多版本并发控制MVCC每个 Key 会保存多个版本的数据通过版本号区分不同事务的修改。比如 Key1 会保存多个版本的 Value读操作可以直接读取对应版本的数据避免了读写阻塞大幅提升了并发性能。3.5 数据模型从表到 KV 的映射一张 MySQL 表在 TiDB 内部的存储逻辑原始表结构┌──────────────────────────────────┐ │ User (id INT PK, name VARCHAR) │ ├──────┬───────────┬───────────────┤ │ id │ name │ _tidb_rowid │ ← 隐式主键 ├──────┼───────────┼───────────────┤ │ 1 │ 张三 │ ... │ │ 2 │ 李四 │ ... │ └──────┴───────────┴───────────────┘ ↓ 映射为 KV 对 ↓ Key: t{TableID}_r{RowID} Value: [col1_val, col2_val, ...] 实际存储: Key: t{53}_r{1} → Value: [1, 张三] Key: t{53}_r{2} → Value: [2, 李四] 索引的存储: Key: t{53}_i{IdxID}_{col_val}_{RowID} Value: [空]核心思想把关系型数据库的表和索引全部映射成扁平的 Key-Value 键值对。这样不管多复杂的 SQL到了存储层都是 KV 操作极度简洁高效。3.6 Raft 共识协议怎么保证数据不丢这是很多面试必考题Raft 的流程在之前课程已讲过这里不再详细阐述三个关键点写请求只走 Leader保证写入顺序多数派确认才提交3 副本时至少 2 个节点确认自动故障转移Leader 挂了剩余节点自动重新选举四、TiDB SQL 层计算引擎把 SQL 翻译成 KV 操作很多人好奇TiDB 是怎么把 SQL 语句转换成对 TiKV 的读写操作的这就要靠 SQL 层的计算引擎了。1. 数据映射SQL 表 ↔ KV 键值对TiDB 会把关系型数据库的表数据转换成 TiKV 能识别的键值对表数据Key 是t[TableID][RowID]Value 是这一行的列数据比如上面用户表张三的记录就会被转换成对应的键值对存储。索引数据Key 是t[TableID][IndexID][IndexedColumnsValue]Value 是对应的 RowID通过索引可以快速定位到数据行。这种映射方式让 TiDB 可以用键值存储的方式模拟出关系型数据库的完整能力。2. SQL 执行流程从查询到结果的旅程我们执行select count(*) from user where name 张三为例拆解一下执行过程构造 KV 范围根据查询条件生成对应的 Key 范围比如匹配name张三的索引键范围。读取数据向 TiKV 发送请求读取范围内的数据。过滤与聚合TiDB 对返回的数据进行过滤只保留符合条件的记录再执行count聚合操作。返回结果把最终结果返回给客户端。这种计算引擎设计让 TiDB 既支持简单的 CRUD 操作也能处理复杂的聚合查询同时兼容 MySQL 的语法和执行逻辑业务迁移几乎零成本。五、PD 数据调度模块集群的 “智能大脑”PD 作为 TiDB 集群的元数据管理和调度中心很多人只知道它是 “元数据存储”却不知道它的调度能力才是 TiDB 的精髓。1. 核心职责元数据管理存储整个集群的节点信息、Region 分布、数据位置就像集群的 “地图”。数据调度根据集群负载、节点状态自动调整 Region 的分布比如把热点数据迁移到空闲节点保证集群负载均衡。Raft 调度管理 Raft 副本的分布保证每个 Region 的副本分布在不同节点避免单点故障同时自动进行 Leader 负载均衡让读写请求均匀分布。2. 调度场景解决集群的 “疑难杂症”节点扩容新增 TiKV 节点时PD 会自动把其他节点的 Region 迁移过来无需人工干预。节点故障某个 TiKV 节点宕机PD 会自动把该节点上的副本调度到其他节点保证副本数量足够。热点数据某个 Region 的读写请求过高PD 会自动拆分 Region或者把 Leader 迁移到其他节点缓解压力。正是有了 PD 的智能调度TiDB 集群才能实现真正的 “无人值守” 运维大幅降低了分布式数据库的运维成本。调度场景触发条件调度动作Leader 均衡某节点 Leader 过多将部分 Leader 迁移到其他节点Region 均衡某节点 Region 数量过多将部分 Region 副本迁移走热点调度某 Region 读写 QPS 过高分裂 Region分散压力故障恢复某 TiKV 节点宕机自动在其他节点补副本扩容均衡新节点加入自动迁移部分 Region 到新节点六、OLAP 与 TiFlash 列式存储HTAP 的 “最后一块拼图”传统数据库的最大痛点就是 OLTP 和 OLAP 无法兼顾事务型数据库跑报表慢分析型数据库无法支持实时写入。而 TiFlash 的出现让 TiDB 真正成为了一款 HTAP 数据库。1. 什么是 TiFlashTiFlash 是 TiDB 的列式存储引擎专门为 OLAP 场景优化。它会异步同步 TiKV 的数据转换成列式存储格式大幅提升聚合查询、报表分析的性能。2. 行存 VS 列存两种存储的核心差异TiKV行存按行存储数据适合事务型业务快速读写单行数据比如订单创建、用户信息修改。TiFlash列存按列存储数据适合分析型业务比如按用户维度统计订单量、按地区分析销售额列存可以只读取需要的列大幅减少 IO提升查询速度。3. HTAP 场景一次数据写入双场景复用TiFlash 的典型应用场景实时报表业务数据写入 TiKVTiFlash 自动同步数据报表查询直接走 TiFlash无需额外的数据同步和 ETL报表延迟从小时级降到秒级。混合负载业务系统正常进行事务操作同时支持复杂的分析查询互不影响彻底告别 “业务库和报表库分离” 的架构。七、TiDB 落地场景这些业务用了都说香聊完架构和模块很多人会问“我的业务到底适不适合用 TiDB” 结合大厂的落地经验这几个场景TiDB 的优势拉满OLTP 场景替代分库分表的 MySQL业务数据量暴涨MySQL 单库单表撑不住分库分表又太麻烦直接上 TiDB兼容 MySQL 协议业务代码几乎不用改就能获得无限的水平扩展能力金融交易、电商订单、物流轨迹这类高并发事务场景都能完美适配。HTAP 场景事务 分析一体化电商平台的用户行为分析、金融业务的实时风控、零售行业的销售报表这类业务既要支持实时交易又要做复杂分析TiDBTiFlash 的组合直接实现 “一套数据两种用途”省去了数据同步、ETL 的成本还能保证数据的实时性。数据中台场景统一的数据底座企业里多个业务系统的数据孤岛严重数据中台需要一个统一的存储底座TiDB 兼容 SQL、支持分布式事务、能对接各种大数据生态完美适配数据中台的建设需求。写在最后TiDB 不是 “银弹”但它解决了大部分架构难题从业 15 年我见过太多架构师为了数据库的瓶颈头疼不已。TiDB 的出现不是说它能解决所有问题但它用一套架构解决了传统数据库的扩容瓶颈、事务一致性、OLTPOLAP 混合负载的痛点给了我们一个更优雅的选择。各位看官看完 TiDB 的架构设计不知对你手头项目的高可用、高并发架构优化是否带来了一些新思路欢迎在评论区聊聊你的看法论