TiDB数据库

TiDB数据库

TiDB 是一个开源的分布式 NewSQL 数据库，由中国的 PingCAP 公司开发。
它的核心设计目标是提供水平可扩展性、强一致性和高可用性，同时兼容 MySQL 协议，让用户能够像使用 MySQL 一样使用 TiDB。
以下是一些 TiDB 的关键特性和优势：

1.​分布式架构（核心优势）​​：

a.​水平可扩展性​：通过简单地添加新节点（TiKV 存储节点）来扩展存储容量和计算能力（TiDB 计算节点）。理论上容量和性能可以无限扩展（受限于网络等物理因素），有效应对大数据量和高并发场景。
b.​高可用性 (High Availability, HA)​​：数据以 Region 为单位在 TiKV 节点间自动复制（默认 3 副本），存储副本通过 Raft 协议保证强一致性。即使单个或少数节点故障，也能自动进行故障转移，保证服务可用和数据不丢失。

2.​HTAP 能力（混合事务/分析处理）​​：

这是 TiDB 的一大亮点。它使用同一个存储引擎​（TiKV，基于 RocksDB 的分布式 KV 存储）同时支持在线事务处理 (OLTP)​​ 和在线分析处理 (OLAP)​​ 工作负载。通过引入 ​TiFlash 引擎​（列式存储引擎）作为 TiKV 的实时分析副本，使用 Raft Learner 机制异步复制 TiKV 的数据。用户可以在同一份数据上实时运行复杂的分析查询，无需将数据从 OLTP 数据库同步到专门的 OLAP 数据仓库，极大地简化了数据架构，并支持实时业务决策。优化器能智能地将 OLAP 查询路由到 TiFlash，避免影响 OLTP 性能。

3.​兼容 MySQL​：

​协议兼容​：兼容 MySQL 5.7 协议、常用功能及语法。这使得现有的 MySQL 客户端、ORM 框架、中间件和管理工具通常可以无缝迁移或直接连接到 TiDB。​
a.数据迁移方便​：可以使用如 mysqldump、Dumpling（TiDB 的数据导出工具）、或更强大的工具如 TiDB Data Migration 将 MySQL 数据迁移到 TiDB。​
b.降低学习曲线和迁移成本。

4.​强一致性事务​：

基于 Google Spanner 和 Percolator 的思想，在分布式环境下提供 ACID 事务保证（特别是快照隔离级别），通过优化（如两阶段提交的单线程处理优化）减少分布式事务的开销。

5.​云原生设计​：

架构天然适合部署在公有云、私有云或混合云上。提供了 ​TiDB Operator，极大地简化了在 Kubernetes 上 TiDB 集群的部署、运维（升级、扩缩容、配置变更、备份恢复）和自动化管理，使其成为云原生化运维的优选。

6.​开源与活跃社区​：

在 GitHub 上完全开源（https://github.com/pingcap/tidb），拥有非常活跃的国际和国内开发者社区。PingCAP 公司提供商业支持和企业版（提供额外监控工具、诊断工具等）。
​主要组件（核心架构）​​：
1.​TiDB Server（计算层）​​：无状态 SQL 层。接收 SQL 请求，解析、优化查询计划。与 TiKV 交互获取数据（OLTP）。与 TiFlash 交互处理分析查询（OLAP）。兼容 MySQL 协议。
2.​TiKV Server（存储层 - OLTP）​​：分布式键值存储引擎。负责数据持久化（通过 Raft 协议保证数据一致性和高可用）。以 Region 为单位管理数据分布和调度。处理分布式事务（使用 Percolator 模型）。使用 RocksDB 作为底层的单机存储引擎。
3.​TiFlash Server（存储层 - OLAP）​​：列式存储引擎。通过 Raft Learner 机制从 TiKV 异步复制数据，提供实时分析能力。大幅提升复杂聚合查询、大表扫描等 OLAP 操作的性能。提供一致性的快照读。
4.​Placement Driver​：集群的“大脑”。负责全局元数据存储（schema 信息、节点信息）。调度数据（Region）在 TiKV 节点间的负载均衡和位置管理（Leader/Follower 选举）。管理 Raft 组的配置。负责为事务分配全局单调递增的时间戳。
5.​TiDB Dashboard & Monitoring：​​ 提供图形化的管理监控界面（内置和集成 Prometheus/Grafana）。

​典型应用场景​：

​需要水平扩展的关系数据库​：当单机 MySQL 在存储容量、写入/查询性能上遇到瓶颈时。

• ​需要强一致性的分布式事务场景​：如金融交易、订单系统、账户管理等。
• ​HTAP 场景​：需要实时分析处理在线交易数据，希望简化数据栈（无需传统 ETL + 数据仓库）。
• ​SaaS 多租户应用​：天然支持数据分区和扩展。
• ​MySQL 分库分表方案替代​：TiDB 内置的分片透明性极大简化了开发。
• ​IoT/时序数据存储与分析​（虽然专用 TSDB 更优，但 TiDB 也能胜任）。
• ​希望拥抱云原生数据库架构。
  ​

总结​：

TiDB 是一个为解决 MySQL 在分布式、大规模、高并发以及混合负载（HTAP）场景下面临的挑战而设计的现代分布式数据库。它通过分布式架构提供近乎无限的扩展能力、通过 Raft 协议提供强一致性和高可用性、通过 TiFlash 实现实时的 HTAP 能力，并极大地简化了用户的使用和迁移成本（兼容 MySQL）。它是一个在分布式事务数据库领域非常成功和有影响力的开源产品，特别适合业务高速发展、数据量和复杂度激增的企业级应用场景。

TiDB如何做到强一致性事务

TiDB 实现强一致性分布式事务的核心在于结合了 ​Percolator 事务模型、基于 ​Raft 协议的分布式复制​ 以及 ​全局统一的时间戳分配机制 (TSO)​。下面详细分解其实现原理：
​核心机制：​​
1.​MVCC (多版本并发控制):​​TiDB 为每个数据修改保存多个版本。每个数据版本都带有两个特殊的时间戳字段​：start_ts: 事务开始读取/修改该数据的时间戳（事务开始时获取）。commit_ts: 事务成功提交时被分配的时间戳。​
a.数据物理表示为：Key_Ver => (start_ts, commit_ts, Value)。
2.​Google Percolator 事务模型:​​TiDB 的事务处理主要基于 Percolator 模型，并进行了一些优化。
a.​核心思想：主锁 + 乐观锁 + 两阶段提交 (2PC) + 超时/清理机制。​​​
b.两阶段提交 (2PC):​​​Prewrite 阶段 (Prepare):​​事务执行时，首先从 TSO 获取一个全局唯一的 start_ts。事务需要在修改的所有行中，​选一行作为 Primary Lock (主锁记录)​。通常选一个可能写入冲突较小或操作频繁的行。在目标键值上写入一个 ​Lock (锁记录)​​ 和一个 ​Data (数据记录)​​：​锁记录：​​ 包含主锁的位置、事务 start_ts、锁状态（待提交）、过期时间。
c.​数据记录：​​ 包含 start_ts和未提交的新值（称为 ​Write Record，但带有 start_ts，此时 commit_ts为空）。
i.写入规则：检查目标键值上是否存在其他事务的锁？如果有，等待或回滚（冲突）。
ii.检查目标键值上在 start_ts之后是否有已提交的数据 (commit_ts<= start_ts的最新提交版本)? 确保本次写入基于正确的快照（避免脏写）。如果有 start_ts之后的 commit_ts（由其他后启动但先提交的事务写入），则冲突。
iii.只有所有参与行（包括主锁和二级锁）的 Prewrite 都成功，才进入 Commit 阶段。否则，回滚。​
d.Commit 阶段:​​事务从 TSO 获取 commit_ts。​
e.提交主锁：​​ 写入一条 ​Commit Record​ 到主锁行。这是一个指向数据记录的指针：类型是Put，包含主键、commit_ts、以及对应的带有 start_ts的数据记录位置（即 Key_Ver: start_ts => …）。这个 Commit Record 的写入意味着主锁行的事务提交成功。​
f.异步提交二级锁：​​ 一旦主锁提交成功，客户端或 TiDB 即可向应用程序返回成功。随后异步地对所有其他涉及的键（二级锁）写入对应的 Commit Record(Put)。
g.​清理锁：​​ 在所有键（包括主键和所有二级键）上，提交成功后删除对应的锁记录。
3.​全局唯一的时间戳分配 (Timestamp Oracle - TSO):​​由 Placement Driver 组件提供。为所有分布式事务分配严格单调递增、全局唯一的时间戳 (start_ts和 commit_ts)。这是实现全局一致性快照隔离和事务顺序的关键。所有 TiDB 节点看到的全局时钟是同步的。
4.​分布式复制与高可用 (Raft):​​所有真正的数据（数据记录、锁记录、提交记录）都存储在 TiKV 节点中。TiKV 内部将数据分割成连续的 ​Region。每个 Region 被复制成多个副本（默认 3 个），组成一个 ​Raft Group。​任何数据的写入（Prewrite 中的锁/数据记录，Commit 中的提交记录）都必须成功复制到 Raft Group 中的大多数副本后，才认为写入成功。​​ 这确保了即使在少数节点故障时，已提交的数据也不会丢失。Raft Leader 负责处理该 Region 的读写请求，保证数据的一致性。
​

如何确保强一致性？

​​
1.​原子性 (Atomicity):
a.​​​2PC 保证：​​ Prewrite 阶段所有键写锁成功，Commit 阶段主锁键提交成功才算事务提交。如果主锁提交失败，整个事务回滚。​
b.主锁核心作用：​​ 所有其他二级锁的提交依赖于主锁的状态（通过查找主锁行就能判断整个事务的状态）。
2.​一致性 (Consistency):​​数据库约束（唯一性、外键等）在 SQL 层和应用层面保证。内部状态（版本链、锁）通过 MVCC 和事务协议保证一致性。
3.​隔离性 (Isolation) - 默认快照隔离：​​​MVCC + TSO:​​ 事务启动时获取 start_ts，事务执行过程中只能看到 commit_ts <= start_ts的已提交数据版本，确保了快照读取。其他事务在它之后提交的数据 (commit_ts > start_ts) 不可见。​
a.冲突检测：​​​
i.写写冲突：​​ Prewrite 阶段检查锁。如果发现目标键上有其他未提交的锁，或发现了在 start_ts之后提交的版本（即出现冲突写入），事务失败（回滚或重试）。
ii.​读写冲突：​​ 读取碰到未提交的锁（start_ts介于其 start_ts和 commit_ts之间）时，TiDB 可以采取不同策略（如等锁超时、或忽略锁读取最新提交的数据）。
4.​持久性 (Durability):​​​
a.Raft 复制保证：​​ 所有数据（包括锁记录、提交记录和最终的数据记录）在写入时，必须由对应 Region 的 Raft Leader 成功写入到多数副本的持久化存储（RocksDB）中。只要多数副本存活，数据就不会丢失。
​关键点总结：​​

• ​乐观锁：​​ TiDB 默认使用乐观事务模型，先执行再检测冲突（Prewrite 阶段检测）。
• ​主锁决议：​​ 整个事务的状态由主锁行的状态决定。
• ​全局时间戳：​​ TSO 提供严格递增的时钟，是构建全局一致性视图的基础。
• ​异步提交：​​ 二级锁的提交是异步进行的，提高了主锁提交成功的速度。
• ​复制保障：​​ Raft 协议保证了每一个写入（无论是锁、数据还是提交记录）的高可用和持久化。
• ​锁清理机制：​​ 存在后台机制（垃圾回收和锁解析器）来处理异常情况（如事务超时未提交、宕机导致锁遗留），保证系统最终一致并可用。
  正是通过以上这些机制的协同工作，TiDB 在分布式环境下实现了满足 ACID 要求的强一致性事务，特别是在默认的 SNAPSHOT ISOLATION级别下提供了高可扩展性和高性能。