核心内容摘要
探索“502887·mooc曰本版课程内容”：解锁你的日语学习新纪元
深入解析分布式数据库 TiDB 核心架构基于 Raft 一致性协议与 HTAP 混合负载实现金融级高可用与实时分析的工程实践在数字化转型的浪潮中传统单体数据库正面临前所未有的挑战海量数据的存储瓶颈、高并发场景下的性能天花板以及业务对实时分析的迫切需求。
TiDB 作为新一代分布式关系型数据库凭借其云原生架构、Raft 一致性协议保障的金融级高可用以及 HTAP混合事务/分析处理能力成为了众多企业架构升级的首选。
本文将深入剖析 TiDB 的核心架构通过 Mermaid 图解其内部工作原理并探讨在实际工程中如何利用 TiDB 实现高可用与实时分析。
TiDB 宏观架构计算存储分离的云原生设计TiDB 的核心设计理念是“计算存储分离”与“分层解耦”。
整个架构主要由三个核心组件构成TiDB Server计算层、PD (Placement Driver)管理层和 TiKV (存储层)。
此外为了增强实时分析能力引入了 TiFlash 组件。
1 架构全景图渲染错误:Mermaid 渲染失败: Parse error on line 6: ...d subgraph 管理层 PD1[PD Leader]... ----------------------^ Expecting SEMI, NEWLINE, SPACE, EOF, GRAPH, DIR, subgraph, SQS, end, AMP, COLON, START_LINK, STYLE, LINKSTYLE, CLASSDEF, CLASS, CLICK, DOWN, UP, NUM, NODE_STRING, BRKT, MINUS, MULT, UNICODE_TEXT, got STR组件职能解析TiDB Server无状态的 SQL 层负责解析 SQL、生成执行计划、事务协调。
它本身不存储数据可以无限水平扩展。
PD (Placement Driver)整个集群的“大脑”管理元数据调度数据在 TiKV 之间的均衡同时也负责分配全局授时。
TiKV分布式 Key-Value 存储引擎基于 RocksDB 构建负责持久化数据使用 Raft 协议保证数据强一致性。
TiFlash自动从 TiKV 复制数据的列式存储扩展用于加速分析型查询AP。
存储引擎 TiKV 与 Raft 一致性协议详解TiDB 的高可用基石在于 TiKV而 TiKV 的核心在于 Raft 一致性协议。
数据在 TiKV 中被切割成若干个Region每个 Region 默认存储 96MB 数据是数据移动的基本单位。
1 Region 副本与 Raft Group为了保证数据不丢失每个 Region 都有 3 个副本默认分布在不同机器上形成一个 Raft Group。
渲染错误:Mermaid 渲染失败: Parse error on line 21: ...33,stroke-width:4px ----------------------^ Expecting SEMI, NEWLINE, SPACE, EOF, GRAPH, DIR, subgraph, SQS, end, AMP, COLON, START_LINK, STYLE, LINKSTYLE, CLASSDEF, CLASS, CLICK, DOWN, UP, NUM, NODE_STRING, BRKT, MINUS, MULT, UNICODE_TEXT, got 1工作流程Leader 选举当 Leader 所在节点宕机Follower 会通过 Raft 协议自动选举出新的 Leader通常在选举超时 10 秒内完成。
日志复制客户端的写请求只发给 Leader。
Leader 将写操作作为日志条目复制到 Followers。
一旦大多数节点确认收到日志Leader 就提交事务并应用状态机写入 RocksDB。
故障恢复若某节点故障恢复后会通过 Raft 的 Log Matching 属性自动从 Leader 同步缺失的数据。
2 Multi-Raft 模型TiKV 使用了 Multi-Raft 模型即一台物理机上同时运行着成千上万个 Raft 实例。
渲染错误:Mermaid 渲染失败: Parse error on line 8: ...3[Node 3: 3 Regions]/Follower Node3 -----------------------^ Expecting SEMI, NEWLINE, SPACE, EOF, SHAPE_DATA, STYLE_SEPARATOR, START_LINK, LINK, LINK_ID, got NODE_STRING这种设计带来了极大的弹性数据以 Region 为单位在节点间调度。
如果某节点负载过高PD 会将该节点上的部分 Region Leader 迁移到空闲节点实现负载均衡。
分布式事务与 SQL 层实现TiDB 兼容 MySQL 协议但底层是分布式 KV 存储。
TiDB Server 负责将关系型模型映射到 Key-Value 模型并实现分布式事务。
1 Key-Value 映射与数据分布TiKV 的 Key 是有序的。
TiDB 使用特殊的编码方式将表数据映射为 KV 对。
渲染错误:Mermaid 渲染失败: Parse error on line 6: ...y1[t... Row2 --|授时机制 Row3 --|编 ----------------------^ Expecting SQE, TAGEND, UNICODE_TEXT, TEXT, TAGSTART, got PIPE
2 两阶段提交 (2PC)TiDB 使用 Google Percolator 模型实现分布式事务保证 ACID 中的原子性和隔离性。
TiKVTiKV_Leader2TiKV_Leader1PDTiDBClientTiKVTiKV_Leader2TiKV_Leader1PDTiDBClient客户端执行 DML (预写)BEGIN获取全局时间戳 TSstart_tsPrewrite (Key1, Value1, start_ts)Prewrite (Key2, Value2, start_ts)Success (加锁)Success (加锁)COMMIT获取提交时间戳commit_tsCommit (primary key, commit_ts)Commit (secondary keys, commit_ts)Transaction Success关键点全局时间戳 (TSO)由 PD 分配单调递增的时间戳用于确定事务的全局顺序。
Prewrite 阶段数据被写入但未对其他事务可见并在 Key 上加锁。
Commit 阶段首先提交 Primary Key成功即代表事务成功异步提交 Secondary Keys减少网络往返开销。
HTAP 混合负载TiDB 的“双引擎”驱动TiDB 最具创新性的特性之一是 HTAP (Hybrid Transactional/Analytical Processing)即在同一个系统中同时支持事务型 (OLTP) 和分析型 (OLAP) 负载。
1 TiFlash实时同步的列存引擎TiKV 是行存引擎适合点查和事务处理TiFlash 是列存引擎适合大规模扫描和聚合计算。
TiFlash 通过 Raft Learner 协议以强一致性的方式从 TiKV 同步数据。
AP 查询加速读行存读列存写入请求TiKV 行存事务处理Raft LogTiKV Follower行存副本TiFlash Learner列存副本复杂分析 SQL智能路由TiFlash 列存节点核心优势实时性数据写入 TiKV 后毫秒级同步至 TiFlash分析查询几乎无延迟RPO 接近 0。
一致性通过 Follower/Learner 机制TiFlash 读取的数据快照与 TiKV 完全一致避免了传统 ETL 同步导致的数据不一致问题。
透明性用户无需修改 SQLTiDB 优化器会自动判断基于成本估算是走 TiKV 还是 TiFlash或者利用 MPP (Massively Parallel Processing) 模式并行计算。
2 MPP (大规模并行处理)TiFlash 引入了 MPP 架构允许将大查询拆分发到多个 TiFlash 节点上并行执行中间结果在节点间交换Exchange最后汇总。
TiFlash MPP 集群TiDB 计算层下发 MPP 任务下发 MPP 任务Exchange 数据Exchange 数据最终结果TiDB ServerNode 1: Scan FilterNode 2: Scan FilterNode 3: Aggregation这使得 TiDB 在处理亿级数据关联查询时性能可媲美甚至超越传统数仓。
工程实践金融级高可用与容灾在金融场景下数据一致性RPO0和服务可用性RPO 30s是硬指标。
1 三机房五副本 / 同城多活架构利用 Raft 协议的特性TiDB 可以灵活配置副本的拓扑分布。
机房 B (实时灾备)机房 A (核心写入)配置策略Vote: LeaderVote: FollowerVote: FollowerPD Placement RuleRegion Raft Group实战策略Raft 成员规则通过 PD 的 Placement Rules强制 Leader 固定在性能最强的机房并保证任意两个机房加起来的票数超过大多数例如 3 副本分布
或
。
故障自动切换当机房 A 发生断电或火灾Raft Group 自动在剩余机房选举新 Leader业务几乎无感知取决于应用层重试机制。
binlog 同步对于需要跨地域容灾如北京到上海的场景可使用 TiCDC 或 Drainer 实现增量数据同步构建主备集群。
2 运维与弹性伸缩TiDB 的云原生特性极大地简化了运维。
扩缩容存储扩容新增 TiKV 节点PD 自动检测到新节点开始将其他节点上的 Region 搬运至新节点达到负载均衡。
计算扩容新增 TiDB 或 TiFlash 节点无需数据搬迁立即承担计算压力。
OldNodesNewNodePDAdminOldNodesNewNodePDAdmin扩容指令 (Add Node)初始化新节点上报心跳 (容量大, 负载低)计算调度计划迁移 Region Leader/Follower数据迁移报告 Region Ready扩容完成
6.
总结TiDB 通过融合 Google Spanner 和 Google F1 的设计思想在开源界实现了一套成熟的企业级分布式数据库解决方案。
架构层面计算存储分离架构保证了极致的弹性与扩展性。
一致性层面基于 Multi-Raft 的强一致性协议在保证高性能的同时实现了金融级的数据安全。
混合负载层面TiKV TiFlash 的 HTAP 架构打破了事务与分析的壁垒让实时决策成为可能。
工程实践层面通过智能的 PD 调度和灵活的副本规则TiDB 能够适应从三机房到跨地域的各种复杂容灾需求。
对于正面临传统数据库瓶颈且需要在保证事务强一致的前提下实现实时数据分析的企业来说TiDB 提供了一条平滑且高效的演进路径。