免费领取阿里云大礼包3150元+新客享0.26折起优惠

gydtep2002

原生的 InnoDB 引擎无法满足我们支持 TSO 事务的需求，因此我们修改了 InnoDB 引擎的提交逻辑和可见性判断逻辑，在 XA BEGIN 和 XA COMMIT 前插入了我们自定义的两个变量 SNAPSHOT_TS 和 COMMIT_TS。

• SNAPSHOT_TS 用于判断其他事务提交数据对当前事务的可见性，统一了一个分布式事务在每个分片上进行读取发生的时间。SNAPSHOT_TS 决定了当前事务的快照。

gydtep2002

如果在提交阶段我们发现事务只涉及了一个分片，那么我们就会将其优化为一阶段提交，使用 XA COMMIT ONE PHASE 语句提交事务。对于正常的 TSO 事务，我们取了 SNAPSHOT_TS 和 COMMIT_TS 两个时间戳，而对于一阶段提交的事务来说，其实行为与单机事务类似，因此我们并不需要通过 TSO 获取 COMMIT_TS，而是可以直接由 InnoDB 计算出一个合适的 COMMIT_TS 来提交事务。具体的计算规则是：COMMIT_TS = MAX_SEQUENCE + 1，其中 MAX_SEQUENCE 为 InnoDB 本地维护的历史最大的 snapshot_ts。

gydtep2002

本文主要介绍了 PolarDB-X 2.0 中的 TSO 分布式事务的实现。相比于 PolarDB-X 1.0 （DRDS）默认的 XA 事务，TSO 事务性能更优：通过 MVCC 方式避免加读锁，同时通过一系列优化（例如异步提交）提升了性能。此外借助 TSO 事务还提供了备库一致性读的能力。

gydtep2002

这主要因为 CNCF 基金会在当时的核心拳头软件就是 K8s，因此在概念定义上主要是围绕着容器编排建立起来的生态。其实这也是为什么我们可以看到 CNCF 定义云原生的时候有时感觉就是再说容器生态。

到了 2017 年, 云原生应用提出者之一的 Pivotal 在其官网上将云原生的定义概括为 DevOps、持续交付、微服务、容器四大特征，这也成了很多人对 Cloud Native 的基础印象。

gydtep2002

概念随着新的技术发展而演化

第一阶段：容器化封装+自动化管理+面向微服务
第二阶段：DevOps、持续交付、微服务、容器
第三阶段：DevOps、持续交付、容器、服务网格、微服务、声明式API

gydtep2002

组织结构 - 康威定律
设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。通俗来讲，就是什么样的团队结构，就会设计出什么样的系统架构。如果将团队拆分为前端、后端、平台、数据库，那么系统也会按照前端、后端、平台、数据库结构隔离。

gydtep2002

当这些 BaaS 云服务日趋完善时，Serverless 因为屏蔽了底层设施的运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。Serverless 计算包含以下特征：

全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基础设施开发、运维、安全、高可用等工作。
通用性，结合云 BaaS API 的能力，能够支撑云上所有重要类型的应用。

gydtep2002

Service Mesh 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注 微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。换句话说，因为大量非功能性从业务进程剥离到另外进程中，Service Mesh 以无侵入的方式实现了应用轻量化

gydtep2002

如果多个服务分别向三个节点写数据，为了保证强一致，就必须要求三个节点全部写成功才返回；同步写三个节点的性能较低，如果换一个思路，一致性并不一定要在写数据的时候完成

gydtep2002

技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。

加快系统演进速度：每一个应用都可以独立的进行版本更新，通过灰度发布等技术手段能确保发布过程中整个系统稳定运行。