5.4 事务优化
说明
下文中提到的事务模型，均涉及 3 条 select、9 条 insert，总共 9 张表的操作。
优化一：提前响应客户端
OceanBase 1.0 单机分布式事务提交，prepare 阶段完成之后立即应答客户端。相对于传统两阶段提交协议，降低了事务 RT，提升了系统的吞吐能力。
事务 Commit RT = 1 次磁盘 IO + 2 轮 RPC 通信；整个事务的日志条数：3 * 9 = 27。
优化二：一阶段提交（1 PC）
OceanBase 2.0 采用了 Batch Commit 的优化思路，让单机分布式事务走一阶段提交成为可能。事务 Commit RT 不变，降低了 66.6% 的日志条数，性能提升显著。
1PC 优化前提：
事务所有参与者 Leader 在同一台机器，且 memble list 分布一致。
所有参与者 redo log 总量不超过 1.875M。
事务 Commit RT = 1 次磁盘 IO；整个事务的日志条数：9 * 1 = 9。
优化 3：Partition Group（PG）
借鉴 MySQL、Oracle 事务提交机制，在一阶段提交基础上，OceanBase 2.2 采用了分区聚合的思路，让一阶段提交的日志条数继续降低 90%，性能提升显著。
T1、T2、T3 分别为三个不同的业务表，按照相同的分区方式（hash、list 等）分为 3 个 partition。
优化效果：事务 Commit RT 时间 = 1 次磁盘 IO，整个事务的日志条数 = 1 * 1 = 1。
小结
| 事务类型 | CommitRT | 总日志量 | 备注 |
|---|---|---|---|
| 传统两阶段提交 | 4 次磁盘 IO | 2 + 2 * 9 = 20 | 参与者和协调者均需要写 prepare、commitlog |
| 提前响应客户端 | 1 次磁盘 IO | 3 * 9 = 27 | 只需要参与者写 prepare、commitlog |
| 一阶段提交 | 1 次磁盘 IO | 1 * 9 = 9 | 只需要参与者写 preparelog |
| PartitionGroup | 1 次磁盘 IO | 1 | PartitionGroup 只需要写一条日志 |
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
