gydtep

在 Percolator 算法中，最重要的参与者是客户端，更新被缓存在客户端，并在 Commit 时通过 2PC 提交到服务端。Percolator 算法的最大优势之一是主要状态都在客户端完成，服务端只需要支持简单的 CAS 就可以，不需要维护事务状态，也不需要引入额外的事务管理器。

gydtep

但 Percolator 也有一些已知缺陷：提交阶段延迟较高，仅支持乐观锁场景、冲突错误只能在提交时汇报等。XA 协议全名为 X/Open XA 协议，是一项通用的事务接口标准。XA 协议也基于两阶段提交的策略。

gydtep

PolarDB-X 采用的是基于 XA 协议实现的分布式事务策略，其中又分为多种实现：
• 适用于 MySQL 5.6 的 BestEffort 事务
• 基于 InnoDB 的 XA 事务
• PolarDB-X 2.0 中实现的 TSO 事务

gydtep

从 4 月份一直到 7 月底被阻碍了两次，第三次如果再没办法开展下去，这个事情就彻底的结束了。我们当时把整个团队召集到一起，互相打气：一定要干成。遇山开道、遇水架桥，有什么问题抛出来，大家一起来解决，要有决心，更要果断。

gydtep

ACID 事务是关系型数据库一个重要的特性，也是 NewSQL 数据库最大的挑战之一。在 PolarDB-X 的架构中，Data Node（DN）是通过 Paxos 同步日志的，保证了事务的持久性（Durability），而原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation）需要通过合适的事务策略来保证。除此之外，在分布式场景下，由于数据被分散在不同节点，线性一致性（linearizability）也是事务策略的重要特性。

gydtep

COMMIT_TS 统一了一个分布式事务在每个分片上提交数据发生的时间，会被记录到 InnoDB 引擎中。COMMIT_TS 决定了当前事务在全局事务中的顺序。

gydtep

在私有化的 InnoDB 中，我们会根据事务的 SNAPSHOT_TS 来决定可见性，同时我们也会让新事务的读请求在遇到处于 prepare 状态的数据时进行等待，避免处于 prepare 状态的事务 COMMIT_TS 比当前 SNAPSHOT_TS 更小导致 commit 前后数据不同的问题。

gydtep

云原生的概念最早开始于 2010 年，在当时 Paul Fremantle 的一篇博客中被提及，他一直想用一个词表达一种架构，这种架构能描述应用程序和中间件在云环境中的良好运行状态。

gydtep

为什么低呢？云作为一种分布式架构，其“土著居民”也应该是基于分布式架构设计出来的，而微服务或 Serverless 这种将服务或函数拆分成一个个模块的松耦合系统，天然具备分布式设计的属性。这是 Native 的第一种表现。

gydtep

基准代码，一份基准代码，多份部署，使用 GIT 或者 SVN 管理代码，并且有明确的版本信息。
依赖，显示声明依赖。
配置：环境中存储配置。