共计 4614 个字符，预计需要花费 12 分钟才能阅读完成。
简介：2003 年淘宝网成立之后，业务飞速发展，其后盾架构也进行了屡次迭代。2009 年之前，淘宝网后盾的数据库架构是经典的 IOE 组合。IOE 是指 IBM 的小型机、Oracle 的数据库加上 EMC 的高端存储。这套组合老本昂扬，但仍然无奈满足淘宝网对于高并发、大容量的扩展性需要。
好的 MySQL 兼容性能够做到什么水平
PolarDB-X 如何做生态兼容
——吴学强（燧木）
阿里云数据库高级技术专家
理解更多 PolarDB-X 内容：https://developer.aliyun.com/…
家喻户晓，数据库是根底的软件系统，而根底的软件都有本人的生态。生态的构建有两种范式，第一种范式是从 0 到 1 的构建，第二种是基于已有的生态持续演变。
分布式数据库是数据库畛域的热门方向，目前已有十分多的开源我的项目。这些开源的我的项目大多都抉择了第二种形式，即从已有的 MySQL 或 Oracle 生态进行本人的生态构建。
而采纳第二种形式，就不得不思考与已有生态的兼容性。兼容性并不是 0 和 1 的二分区别，用兼容度来表白会更主观。作为新的数据库，更应该关注的是它解决了什么新的问题或是带来了什么新的个性。
一、为什么要兼容 MySQL
image.png
2003 年淘宝网成立之后，业务飞速发展，其后盾架构也进行了屡次迭代。2009 年之前，淘宝网后盾的数据库架构是经典的 IOE 组合。IOE 是指 IBM 的小型机、Oracle 的数据库加上 EMC 的高端存储。这套组合老本昂扬，但仍然无奈满足淘宝网对于高并发、大容量的扩展性需要。
为了解决这两个问题，2009 年，淘宝发动了“去 IOE”静止，其指标是用自研的分库分表中间件 TDDL 加本人保护的 MySQL 分支 AliSQL 来替换 IOE 组合。这套架构在 2011 年双 11 大促的时候，胜利接管了交易的外围库之一——商品库，从而验证了 TDDL +AliSQL 计划的可行性。
随同着此套计划的遍及，“去 IOE”流动在 2013 年正式完结，TDDL +AliSQL 组合成为了阿里巴巴所有业务接入数据库的规范。
同时因为 TDDL +AliSQL 组合，即分库分表中间件 + MySQL 形式在阿里的胜利验证，其余国内互联网厂商也都紧随其后，分库分表中间件的计划在国内失去了遍及。
2015 年，TDDL 以中间件的状态在阿里云上公布，名为 DRDS，即分布式关系型数据库。
image.png
尔后，DRDS 持续迭代。迭代过程中，也尝试解决了中间件状态几个比拟大的问题。2016 年，通过内部零碎来尝试解决此状态下扩容的问题。2017 年，基于 MySQL XA 实现了内置的分布式事务能力。2018 年，为了解决此组合的运维复杂度，进行了产品状态上一体化设计的尝试。2019 年，阿里对过来 10 年的技术实际和 5 年的上云教训进行了从新思考，并对产品架构做了全新的梳理和设计。
2020，阿里公布了全新一代的产品架构，并将 DRDS 产品品牌降级到了 PolarDB-X。在 2021 年云栖大会，PolarDB-X 正式对外开源。
回顾产品倒退的历史，能够得出两个不言而喻的论断：PolarDB-X 产品的出发点就是 MySQL，因而产品后续的迭代都是以兼容 MySQL 作为指标之一；
第二，通过近 10 年的一直摸索，从中间件状态到分布式数据库状态，并没有不可逾越的技术鸿沟。
二、怎么做兼容：以 CDC 为例
image.png
CDC（Change Data Capture）即增量数据捕获，用来解决一些特定的业务问题。
后盾零碎个别能够分为下层业务零碎和上层数据库系统。业务最原始的数据都存在数据库系统中。一份重要数据有很多问题须要思考，其中之一便是如何解决数据孤岛的问题——如果想进一步开掘这份数据的价值，如何将它与其余生态系统进行互通？
image.png
MySQL 通过 Binlog 个性来买通与上游工具或零碎的互通。Binlog 能够简略地了解为繁多的队列，队列依照工夫程序严格记录了 MySQL 外面所有数据的变更过程。上游工具或零碎通过生产队列来实时获取到 MySQL 里数据的变更。
image.png
PolarDB-X 提供 CDC 能力，首先须要思考是否提供齐全兼容 MySQL Binlog 的 CDC 能力。在分布式系统中提供上述能力，会面临若干问题，而这些问题都由同一个起因引起。
分布式数据库系统中通常有多个计算节点和存储节点，如上图所示的 CN 和 DN 节点。多个节点会产生多个事件队列，会面临以下几个问题：
① 在不同队列里，事件之间的程序如何确定？
② 通常分布式事务会波及到多个队列，如何找到散布事务蕴含的所有增量事件，以保障分布式事务的完整性？
③ 分布式系统中，DDL 操作不可能在所有 CN 或 DN 节点中同时失效，也就意味着在若干个增量的事件队列里，可能会存在不同版本的 schema，如何解决？
④ 分布式系统很大的特点就是弹性，主动扩缩容所引发的事件队列的增减问题如何解决？
针对以上问题进行十分具体的剖析之后，咱们最终得出的论断是：这些问题可解，但代价较高，而最终工程量在可承受范畴之内。因而，咱们将 CDC 这项能力的指标设计为放弃与 MySQL Binlog 的体验完全一致。
实现此性能后，MySQL 可能订阅 Binlog 的工具或零碎，能够从 MySQL 无缝切换到 PolarDB-X，这项能力被称为 Global Binlog (全局 Binlog)。
全局 Binlog 能力已于 2021 年云栖大会公布。尔后咱们进行了继续迭代，包含稳定性相干的持续优化、性能的优化且验证了更多上游工具或零碎。
以 Flink CDC 为例，Flink CDC 曾经提供了 MySQL Connector 的连贯形式。因为 PolarDB-X 提供了一种与 MySQL Binlog 齐全兼容的全局 Binlog 能力，所以能够将 Flink CDC 的 MySQL Connector 间接与 PolarDB-X 进行互通。
最终，从产生接入的想法，到 Flink CDC 的 github 上呈现反对 PolarDB-X 数据库作为源端，整个过程只破费不到一周的工夫，充分证明了做到与 MySQL Binlog 齐全兼容之后带来的便利性。
Global Binlog 与 Flink CDC 连贯演示——双十一交易大屏模仿
image.png
去年在云栖大会开源之后到当初，咱们的工作又有了一些停顿。上图橙色局部是曾经在 2.1 版本里实现的新性能，次要是对上游工具或零碎的验证。
下一步，咱们会验证更多工具，尝试反对 GTID，以及实现 Binlog 多流的能力。
image.png
前文解决了数据库上游的问题，上游的问题也不可漠视。
分布式数据库是用来解决特定的状况下，比方其高并发或扩展性遇到问题的数据库类型，这也意味着业务在上线之初，通常采纳单机状态的数据库。而从原来的单机数据库往散布数据库迁徙或切换时，如何平滑、无效地实现迁徙，也是不得不思考的问题。
MySQL 实现平滑迁徙，次要通过其原生的主备复制能力，以放弃主节点和备节点之间的实时增量同步，即 replication 能力。它所用的 SQL 指令为 change master。
而如果 PolarDB-X 提供同样的能力，是否可行？
通过剖析之后，咱们认为可行，但有肯定的工程量。因而，最初论断仍然是提供与 MySQL 齐全兼容的复制能力，称为 Replica。
Replication 演示
本次演示以 MySQL 为主,PolarDB-X 为备，搭建一条主备同步链路，以展现 PolarDB-X 的 Replica 能力。
以上，这两个例子就是 PolarDB-X 开源后在 MySQL 兼容方向上新退出的一些能力。
image.png
PolarDB-X Replication 领有如下个性：
① 产品体验上，可能反对 MySQL 原生的 change master 指令，即能够在 PolarDB-X 里间接输出 change master 指令来搭建 MySQL 到 PolarDB-X 主备同步链路。
源端也反对以 PolarDB-X 作为主库，意味着可搭建 PolarDB-X 到 PolarDB-X 主备同步的链路。反对 DDL 同步，以及反对事务复制、行级复制，用户能够在性能和事务的完证性两个方面进行抉择。
② 性能方面，单条复制链路目前反对 1.5 万 RPS，没有大事务等非凡场景下，反对 1 秒以内的同步提早。
③ 目前已验证的上游零碎包含 MySQL/ MariaDB 和 PolarDB-X，后续会尝试验证其余零碎。
下一步，咱们的工作次要将围绕以下三方面发展：接入多流能力，使得 PolarDB-X 和 PolarDB-X 之间的同步链路有更强的性能加强；适配 global Binlog 的 GTID 能力，使得同步链路在事务复制时能够反对并行复制能力；适配更多源端。
三、齐全兼容 MySQL 吗
image.png
MySQL 是非常复杂的零碎，能够将其拆解为若干个性或性能项，再进行逐项剖析。
首先，个性的重要性如何？上图中以扇形对应的角度来示意；其次，PolarDB-X 在这项能力上对 MySQL 的兼容水平有多少？上图中以扇形半径来示意。如果 PolarDB-X 做到了与 MySQL 个性齐全兼容，扇形的半径应该与里面圆的半径相等；如果只做到局部兼容，则扇形离圆的边缘有一部分空白；如果目前 PolarDB-X 还不反对此个性，则对应的扇形为空白。
上图显示了评估后的后果。能够看出 PolarDB-X 在根底能力的兼容性上总体体现不错；高级个性也兼容了很大一部分，然而有局部个性仍然不兼容。
PolarDB-X 的指标并不是齐全兼容 MySQL，而在于上图的下半局部圆—— PolarDB-X 对 MySQL 数据库更多能力的加强或新增。比方并发的读 / 写、存储容量、单表的容量、弹性、高可用和容灾、HTAP、企业级个性等能力，绝对 MySQL 都有了十分大的加强。
四、进入 Kubernetes 生态
PolarDB-X 也是云原生的数据库，而云原生以 K8S 为底座。
因而，PolarDB-X 在 K8S 上也做了十分多工作，比方基于 K8S 进行了资源的编排、构建了 CICD 流程、进行混沌测试等。
2021 年云栖大会，咱们凋谢了最根底的 PolarDB-X Operator 能力。而 PolarDB-X 2.1 最新版新增了基于 Prometheus+Grafana 监控的零碎，加强了可观测性。
image.png
上图为监控零碎页面截图，展现了零碎的资源、QPS 等丰盛的监控维度。用户能够在 github 仓库上下载、装置和体验。
另外，咱们对 Operator 也进行了继续迭代。此前提供的 Operator 只具备根本实例生命周期的治理能力，比方实例的创立、销毁等。后续已新增比方扩缩容、升降配、数据主动 rebalance 等能力。
image.png
在 K8S 方向上，咱们还有丰盛的布局。上图展现了后续打算的工作。
绿色局部是目前曾经实现的，用户能够通过开源仓库进行体验：
生命周期治理上，提供实例的创立、删除、升降级等；
弹性上，反对实例的程度扩缩容、垂直扩缩容、数据 rebalance 等；
高可用和容灾上，反对 CN 高可用、DN 高可用、GMS 高可用、CDC 高可用等；
监控上：反对反对 CN 监控、DN 监控、GMS 监控等。
黄色局部代表以后正在研发的能力，比方备份复原、SQL 审计、Dashboard、数据透视等。
红色局部代表将来更长期的布局，比方国产化、参数设置性能等。
以上就是咱们在云原生能力上的一个布局，后续也会有节奏的凋谢给用户应用。
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。
