percolator

参考文章： TiDB 和 MySQL的差异 站在业务开发的视角，TiDB 最吸引人的几大特性是： 支持 MySQL 协议（开发接入成本低）； 100% 支持事务（数据一致性实现简单、可靠）； 无限水平拓展（不必考虑分库分表）。 基于这几大特性，TiDB 在业务开发中是值得推广和实践的，但是，它毕竟不是传统的关系型数据库，以致我们对关系型数据库的一些使用经验和积累，在 TiDB 中是存在差异的，现主要阐述“事务”和“查询”两方面的差异。 TiDB 事务和 MySQL 事务的差异 MySQL 事务和 TiDB 事务对比 在 TiDB 中执行的事务 b，返回影响条数是 1（认为已经修改成功），但是提交后查询，status 却不是事务 b 修改的值，而是事务 a 修改的值。 可见， MySQL 事务和 TiDB 事务存在这样的差异： MySQL 事务中，可以通过影响条数，作为写入（或修改）是否成功的依据；而在 TiDB 中，这却是不可行的！ 作为开发者我们需要考虑下面的问题： 同步 RPC 调用中，如果需要严格依赖影响条数以确认返回值，那将如何是好？ 多表操作中，如果需要严格依赖某个主表数据更新结果，作为是否更新（或写入）其他表的判断依据，那又将如何是好？ 原因分析及解决方案 对于 MySQL，当更新某条记录时，会先获取该记录对应的行级锁（排他锁），获取成功则进行后续的事务操作

今日，云原生计算基金会 ( CNCF ) 宣布 TiKV 正式从 CNCF 毕业。TiKV 是继 Harbor 之后在 CNCF 毕业的第二个中国原创开源项目。从孵化项目晋升为毕业项目，标志着 TiKV 在产品成熟度、项目采用率以及社区持续性等方面取得一系列进展，可应用到各类行业、各种规模的生产环境。 TiKV 是一个开源的分布式事务 Key-Value 数据库，专注为下一代数据库提供可靠、高质量、实用的存储架构。最初由 PingCAP 团队在 2016 年 1 月作为 TiDB 的底层存储引擎设计并开发，第一版于 2016 年 4 月开源。2018 年 8 月被 CNCF 宣布接纳为沙箱云原生项目，在 2019 年 5 月从沙箱晋级至孵化项目。目前，TiKV 已经在知乎、一点资讯、Shopee、美团、京东云、转转等多行业头部企业得到上线应用。 TiKV 通过 Raft 一致性算法来实现数据多副本之间的一致性，本地采用了 RocksDB 存储引擎存储数据，同时 TiKV 支持数据自动切分和迁移。TiKV 的跨行事务最初参考 Google Percolator 事务模型，并进行了一些优化，提供快照隔离与带锁快照隔离，支持分布式事务。TiKV 的核心特性如下： 跨区复制：采用 Raft 协议和 Placement Driver 支持跨区复制。 可扩展性：通过 Raft 复制数据以及

1. 引言 分布式事务主要应用领域主要体现在 数据库领域、微服务应用领域。微服务应用领域一般是柔性事务，不完全满足 ACID 特性，特别是 I 隔离性，比如说 saga 不满足隔离性，主要是通过根据分支事务执行成功或失败，执行相应的前滚的重试或者后滚的补偿操作来达成全局事务的最终一致性，但是全局事务与全局事务之间没有隔离性。 笔者了解到的分布式事务方案有 2PC 的 XA 规范，以及 Google 的 percolator 方案（ TiDB 就采用这个实现，本质上是基于全局时间戳的乐观锁版本校验）。 mysql 的 XA 应用场景分为外部 XA 与内部 XA ，内部 XA 用于 binlog 与 stroage engine 之间，协调 binlog 与 redo 事务写入的原子性。外部 XA 用于 mysql 节点与 mysql 节点之间，协调跨物理库之间的原子性。本文主要介绍外部 XA 。 基于 mysql 的 XA 两阶段事务提交(2PC) 分布式事务，需要一个事务协调器（ TransactionManager ）来接受应用提交的全局事务 (Global Transaction) ，全局事务经过 TM 的分解后，分解成多个分支事务 (Branch Transaction) ，每个分支事务在具体的某个 mysql 实例上运行，其中 mysql 作为资源管理器（ Resource