tidb设计杂谈

TiDB在设计上通过多种机制保障分布式事务的强一致性，其核心围绕事务模型、原子性实现、隔离级别及持久化设计展开，具体如下：

事务模型：乐观与悲观并存

乐观事务模型（早期版本）基于Google Percolator模型实现，适用于冲突率低的场景。其特点为：
提交时检测冲突：事务执行期间不加锁，仅在提交阶段通过校验数据的版本号（Timestamp）判断是否发生冲突。
自动重试机制：若检测到冲突，事务会自动回滚并重试，但频繁冲突会导致性能下降。
适用场景：读多写少、冲突概率低的业务（如日志分析、报表生成）。
悲观事务模型（3.0及后续版本）针对高冲突场景（如金融交易）优化，通过预锁资源避免冲突：
事务开始时加锁：在修改数据前，先对主键或唯一索引加悲观锁，阻止其他事务并发修改。
减少回滚开销：避免乐观模型中因冲突导致的频繁重试，提升高并发写入场景的吞吐量。
4.0版本增强：支持更细粒度的锁控制（如行级锁），并优化锁超时与死锁检测机制。

原子性保障：两阶段提交（2PC）与Region级原子性

两阶段提交（2PC）TiDB作为分布式数据库，通过2PC确保跨节点事务的原子性：
准备阶段（Prepare）：协调者（TiDB Server）向所有参与者（TiKV Region）发送准备请求，参与者将数据写入日志并返回成功响应。
提交阶段（Commit）：协调者收到所有参与者响应后，统一发送提交命令，参与者完成数据持久化。
容错处理：若部分节点失败，协调者会通过日志回滚未提交事务，保证全局原子性。
Primary Key所在Region的原子性
TiDB将数据按主键范围划分为多个Region（数据分片），每个Region由多个副本（Raft Group）存储。
事务修改数据时，以Primary Key所在Region为基准，通过Raft协议确保该Region的修改原子性，再依赖2PC协调其他Region。

隔离级别：默认可重复读（Repeatable Read）

可重复读（RR）
一致性视图保障：事务开始时生成全局一致的快照（Snapshot Isolation），事务内所有读操作均基于此快照，即使其他事务修改数据，当前事务读取结果不变。
避免幻读：通过MVCC（多版本并发控制）机制，结合Gap Lock（悲观事务下）或唯一索引校验（乐观事务下）防止幻读。
适用场景：需要强一致性读的业务（如订单查询、财务核对）。
其他隔离级别支持
读已提交（Read Committed）：通过配置开启，适用于对一致性要求较低的场景（如监控数据统计）。
串行化（Serializable）：通过乐观锁或悲观锁模拟，但性能开销较大，仅用于极端一致性需求场景。

持久化设计：Raft协议与数据强一致

TiKV的Raft存储引擎
多副本冗余：每个Region的数据通过Raft协议同步到多个副本（默认3副本），确保部分节点故障时数据不丢失。
强一致性写入：数据写入需经过多数派副本确认（Quorum），提交成功后即持久化，即使TiDB Server宕机，数据仍可从TiKV恢复。
自动故障恢复：Raft Leader选举机制自动切换故障节点，保证服务连续性。

设计优势与适用场景

优势
灵活性：支持乐观/悲观事务模型，用户可根据业务冲突率选择。
高可用：通过Raft协议实现数据多副本，满足金融级数据可靠性要求。
水平扩展：Region自动分裂与负载均衡，支持海量数据存储与高并发访问。
适用场景
金融行业：悲观事务模型避免高频冲突下的性能衰减，保障交易一致性。
高并发OLTP：可重复读隔离级别与2PC原子性支持电商、社交等场景的强一致需求。
HTAP混合负载：通过TiFlash列存引擎实现实时分析，事务模型保障分析数据时效性。

总结：TiDB通过乐观/悲观事务模型、2PC原子性协议、可重复读隔离级别及Raft持久化机制，构建了兼顾一致性与性能的分布式数据库设计，能够灵活适配从金融交易到大数据分析的多样化场景。

热门标签