关于tidb 分布式事务

[小学童啊]

事务开始，从PD组件获取开始的时间戳
数据读出到 tidb内存，在内存中进行修改，一旦遇到commit,就需要持久化了，就进入两阶段提交了，
第一阶段：将在tidb-server 内存中修改的数据，锁信息，都写入tikv节点中，
第二阶段：向PD申请时间戳，即事务的结束时间，写提交信息

以上我这样描述正确吗，我怎么觉得，视频讲了很久，我最后弄明白的就是这一段话这么少呢？

[哈喽沃德]

1. 事务开始

你提到的“从 PD 组件获取开始的时间戳”是 TiDB 中的一个重要步骤，称为 分布式事务的时间戳管理。在 TiDB 中，事务的开始和结束时间戳是由 PD（Placement Driver） 组件来协调和分配的。

• 开始时间戳：TiDB 请求 PD 获取一个时间戳，这个时间戳表示事务开始的时刻。
• 时间戳的作用：该时间戳在 TiDB 中用于隔离不同事务之间的读写操作，确保事务的可序列化性。

2. 数据读出到内存

你提到“数据读出到 TiDB 内存，在内存中进行修改”，这也是 TiDB 在执行事务时的一个重要步骤。实际上，TiDB 作为一个 SQL 层，将数据从 TiKV（存储层）读取到内存中进行操作。这个过程中：

• TiDB 可能会先将数据从 TiKV 读到内存，然后在内存中执行 SQL 操作。
• 在这个过程中，TiDB 会维护 锁信息，确保事务的隔离性，例如对读写数据加锁，避免并发操作带来不一致性。

3. 进入两阶段提交（2PC）

当事务准备提交时，进入了你提到的 两阶段提交（2PC）的阶段。

第一阶段：数据和锁的持久化到 TiKV

• 数据持久化：第一阶段会将内存中的修改（即事务提交之前的所有变更）写入 TiKV 存储。实际上，这一步是向 TiKV 写入 预提交日志（Pre-commit logs） 或者是修改的 键值对。
• 锁信息：TiDB 会向 TiKV 发送锁请求（例如，使用锁表来确保数据的可见性和一致性）。TiKV 会在其本地存储中锁定数据，这一步是为了防止其他事务并发修改相同的数据。
• 这阶段确保数据被持久化并且锁定，但实际上数据还没有最终提交。

第二阶段：向 PD 请求结束时间戳和提交事务

• 这时候，TiDB 会向 PD 组件 请求一个 结束时间戳。这个时间戳标记事务的结束，并确保提交时的顺序性。
• 向 TiKV 提交数据：一旦 PD 返回了结束时间戳，TiDB 会告知 TiKV 事务可以提交。这时，TiKV 会确认所有数据写入，并且移除锁，最终提交事务。
• 最终提交：在 TiKV 中，所有的事务变更才会被持久化并生效，锁也会被释放，整个事务就完成了。