开源分布式数据库PolarDB-X源码解读.pdf

封面页（此页面将由下图全覆盖，此为编辑稿中的示意，将在终稿 PDF 版中做更新）（待分享）卷首语 PolarDB-X 是一款面向超高并发、海量存储、复杂查询场景设计的云原生分布式数据库系统。其采用 Shared-nothing 与存储计算分离架构，支持水平扩展、分布式事务、混合负载等能力，具备企业级、云原生、高可用、高度兼容 MySQL 系统及生态等特点。PolarDB-X 最初为解决阿里巴巴天猫“双十一”核心交易系统数据库扩展性瓶颈而生，之后伴随阿里云一路成长，是一款经过多种核心业务场景验证的、成熟稳定的数据库系统。2021 年 10 月，在云栖大会上，阿里云正式对外开源了云原生分布式数据库PolarDB-X，采用全内核开源的模式，开源内容包含计算引擎、存储引擎、日志引擎、PolarDB-X Operator 等。2022 年 1 月，PolarDB-X 正式发布 2.0.0 版本，继 2021 年 10 月 20 号云栖大会正式开源后的第一次版本更新，更新内容包括新增集群扩缩容、以及 binlog生态兼容等特性，兼容 maxwell 和 debezium 增量日志订阅，以及新增其他众多新特性和修复若干问题。2022 年 3 月，PolarDB-X 正式发布 2.1.0 版本，包含了四大核心特性，全面提升 PolarDB-X 稳定性和生态兼容性，其中包含基于 Paxos 的三副本共识协议。2022 年 5 月，PolarDB-X 正式发布 2.1.1 版本，重点推出冷热数据新特性，可以支持业务表的数据按照数据特性分别存储在不同的存储介质上，比如将冷数据存储到 Aliyun OSS 对象存储上。2022 年 9 月，PolarDB-X 数据库高分通过分布式数据库金融标准验证，共进行了 337 个检测项的验证工作，涉及：架构、运维、安全、容灾、性能等。经专家评审后，PolarDB-X 判定符合的检测项为 323 项，整体测试结果表现优异。2022 年 10 月，PolarDB-X 正式发布 2.2.0 版本，这是一个重要的里程碑版本，重点推出符合分布式数据库金融标准下的企业级和国产 ARM 适配，共包括八大核心特性，全面提升 PolarDB-X 分布式数据库在金融、通讯、政务等行业的普适性。为了帮助大家理清头绪快速上手，我们发布了一系列的文章帮助大家理解 PolarDB-X 源码。本书集合了 PolarDB-X 源码解读系列文章，希望通过这本书，能够让大家深入理解 PolarDB-X。您首先可以了解 PolarDB-X 数据库的基本原理，学到一个数据库是如何实现的。您也可以把 PolarDB-X 的实现原理应用到其他系统，这对您学习其他数据库和分布式系统也有帮助。其次，在熟悉了 PolarDB-X 的代码之后，如果有需要，您可以在遵守开源协议的基础上在未来的工作中使用我们的代码，或者为 PolarDB-X 贡献您的代码。目录 PolarDB-X 源码解读（一）：CN 代码结构.5 PolarDB-X 源码解读（二）：CN 启动流程.13 PolarDB-X 源码解读（三）：CDC 代码结构.22 PolarDB-X 源码解读（四）：SQL 的一生.37 PolarDB-X 源码解读（五）：DML 之 Insert 流程.52 PolarDB-X 源码解读（六）：分布式死锁检测.68 PolarDB-X 源码解读（七）：私有协议连接的一生（CN 篇）.74 PolarDB-X 源码解读（八）：Global Binlog 的一生.97 PolarDB-X 源码解读（九）：DDL 的一生（上）.107 PolarDB-X 源码解读（十）：DDL 的一生（下）.123 PolarDB-X 源码解读（十一）：事务的一生.133 PolarDB-X 源码解读（十二）：谈谈 in 常量查询的设计与优化.151 PolarDB-X 源码解读（十三）：DML 之 INSERT IGNORE 流程.168 PolarDB-X 源码解读（番外）：如何实现一个 Paxos.180 PolarDB-X 源码解读（一）：CN 代码结构 5 PolarDB-X 源码解读（一）：CN 代码结构 本文主要介绍 PolarDB-SQL（即 PolarDB-X CN 计算层）代码结构，首先简要回顾PolarDB-X 的架构，然后从目录入手介绍各个模块的功能，最后列出一些关键接口便于读者调试代码。一、整体架构 PolarDB-X 包含 4 个核心组件构成，CN（Compute Node）负责计算、DN（Data Node）负责存储、GMS（Global Meta Service）负责管理元数据和提供 TSO 服务，CDC（Change Data Capture）负责生成变更日志。其中，CN 作为服务入口，完成三个任务：通过 MySQL 协议接收用户请求，返回结果。作为分布式查询引擎，兼容 MySQL 语法，提供分布式事务、全局索引、MPP 等特性。通过 RPC 协议与 DN 交互，下发读写指令，汇总结果。下文将结合 CN 的三个任务，介绍代码、目录、模块在其中扮演的角色，并给出一些关键接口，便于读者继续探索。PolarDB-X 源码解读（一）：CN 代码结构 6 二、代码简介 CN 代码托管在 GitHub 上，划分为 polardbx-sql 和 polardbx-glue 两个仓库。MySQL 协议实现和分布式查询引擎包含在 polardbx-sql 仓库中，由于 License 原因，与 DN 交互的 RPC 协议相关代码单独放在 polardbx-glue 中。调试代码前，首先需要下载两个仓库的代码。推荐首先下载 polardbx-sql 代码，然后通过 git submodule 引入 polardbx-glue，这样可以独立提交两个仓库的变更，具体步骤参考 contributing 文档。CN 是一个多模块的 Java 项目，模块之间通过接口暴露服务，模块关系记录在pom.xml 中，通过mvn dependency:tree命令可以查看全部依赖。部分接口使用了 SPI 机制，这部分接口需要在模块的src/main/resources/META-INF/polardbx目录下查看当前模块中使用的具体实现。关于编译打包，可以参考编译/初始化文档。CN 的 main 方法在 polardbx-server 模块下的 TddlLauncher 类中，“Tddl”代表“Taobao Distributed Data Layer”，产生于 PolarDB-X 0.5 时代，由于类名被关联系统依赖，保留至今。三、目录与模块 polardbx-sql 项目首页中可以看到很多目录和文件，加上重名为 polardbx-rpc 后加入工程的 polardbx-glue，项目根目录下包含 13 个文件夹，9 个文件。其中，代码目录以 polardbx 开头，docke_build.sh 用于本地生成 docker 镜像，pom.xml 是整个项目的工程文件，saveVersion.sh 用于打 RPM 包时生成版本号后缀。PolarDB-X 源码解读（一）：CN 代码结构 7 根目录中，每个以 polardbx 开头的目录，都代表一个独立的模块，以下展开介绍各个模块。模块 包 简介 polardbx-calcite PolarDB-X 优化器基于 Apache Calcite 框架做了深度定制，该模块用于引入 calcite-core 的代码，定制代码在 polardbx-optimizer 模块下 polardbx-calcite org.apache.calcite.plan.hep RBO 框架 polardbx-calcite org.apache.calcite.plan.volcano CBO 框架 polardbx-calcite org.apache.calcite.sql AST（抽象语法树）节点数据结构 polardbx-calcite org.apache.calcite.rel 逻辑计划相关代码，包括数据结构、优化规则、类型系统以及相关工具类等内容，主要包含 calcite-core 的原始代码，增加的逻辑/物理算子和优化规则放在polardbx-optimizer 模块下 PolarDB-X 源码解读（一）：CN 代码结构 8 polardbx-calcite org.apache.calcite.rex 表达式相关代码，主要包含 calcite-core的原始代码，新增的表达式相关代码放在polardbx-optimizer 模块下 polardbx-calcite org.apache.calcite.schema Catalog 相关接口抽象，具体实现在polardbx-optimizer 模块下 polardbx-common 工具类模块 polardbx-executor 执行器模块，所有执行器代码都在这里，比如 SQL 执行代码，MPP 执行器，异步DDL 引擎，统计信息收集，scaleout，全局二级索引等，内容比较多，后续文章中展开介绍 polardbx-gms 元数据服务模块 polardbx-gms com.alibaba.polardbx.gms.listener 后台监听 metaDb 配置的接口，用于支持CN 感知配置变化 polardbx-gms com.alibaba.polardbx.gms.metadb 读写 schema，table，column，index 等元数据的接口，informaction_schema 中展示的信息大部分通过这里的接口获取。metaDb 是 PolarDB-X 持久化元数据的系统库 polardbx-gms com.alibaba.polardbx.gms.privilege 授权、鉴权、白名单、读写权限信息相关接口 polardbx-gms com.alibaba.polardbx.gms.sync CN 节点间通信相关接口 polardbx-gms com.alibaba.polardbx.gms.topology/ha/locality/partition/tablegroup 数据拓扑相关接口，记录了物理分区分布（topology），leader/follower(ha)，地域（locality），分区（partition），表组（tablegroup）等信息 polardbx-net MySQL 客户端/服务器协议相关接口 polardbx-net http:/ 包含 TCP 包处理类和与客户端交互的协议接口（包括登陆鉴权、文本协议、Prepared Statement 等）polardbx-net com.alibaba.polardbx.rpc.cdc CDC 组件变更日志传递相关接口 polardbx-net com.alibaba.polardbx.ssl SSL 相关处理接口 polardbx-optimizer 优化器模块 polardbx-optimizer com.alibaba.polardbx.optimizer.config.meta 包含从逻辑/物理计划中收集信息的工具类，比如统计查询引用了哪些列，计算查询的统计信息等 polardbx-optimizer com.alibaba.polardbx.optimizer.config.schema/table 库/表元数据相关实现，实现了 org.apache.calcite.schema 中定义的元数据接口 polardbx-optimizer com.alibaba.polardbx.optimizer.core.datatype 数据类型相关代码 PolarDB-X 源码解读（一）：CN 代码结构 9 polardbx-optimizer com.alibaba.polardbx.optimizer.core.function 表达式计算相关代码 polardbx-optimizer com.alibaba.polardbx.optimizer.core.planner RBO/CBO 优化规则 polardbx-optimizer com.alibaba.polardbx.optimizer.core.profiler 执行过程中，收集运行时资源消耗信息 polardbx-optimizer com.alibaba.polardbx.optimizer.core.rel 逻辑/物理算子实现，DQL/DML/DDL/DAL语句经过优化器后，转化为物理算子构成的执行计划 polardbx-optimizer com.alibaba.polardbx.optimizer.core.hint HINT 处理相关代码 polardbx-optimizer com.alibaba.polardbx.optimizer.core.sequence 全局唯一 ID 相关代码 polardbx-optimizer com.alibaba.polardbx.optimizer.core.rule/sharding 分区裁剪相关代码 polardbx-optimizer com.alibaba.polardbx.optimizer.core.view 内置视图的执行计划节点，主要为information_schema 和 SHOW 指令涉及的视图 polardbx-parser 语法解析模块，基于 alibaba/druid 内置的 parser polardbx-rpc 与 DN 通信的相关代码 polardbx-rpc com.alibaba.polardbx.rpc rpc 协议交互代码 polardbx-rpc com.alibaba.polardbx.mysql.cj rpc 协议数据对象 polardbx-rule 拆分规则模块 polardbx-server 服务入口，将其他模块组织在一起，main方法在该模块中 polardbx-server com.alibaba.polardbx.cdc CDC 核心控制模块，包括 CDC 系统库表维护，CDC 元数据初始化，CDC DDL 打标等内容 polardbx-server com.alibaba.polardbx.config 系统配置加载相关代码 polardbx-server com.alibaba.polardbx.manager 管理指令相关代码，用于处理从管理端口传入的指令 polardbx-server com.alibaba.polardbx.matrix SQL 处理内部入口，串联解析，优化，执行流程 polardbx-server com.alibaba.polardbx.server 包含 main 方法和请求处理主流程相关代码 polardbx-server com.alibaba.polardbx.server.handler 解析文本协议和 LoadData 指令的相关代码 polardbx-server com.alibaba.polardbx.server.response 部分管控指令的执行代码 polardbx-transaction 事务管理模块，包含分布式事务的实现代码 PolarDB-X 源码解读（一）：CN 代码结构 10 polardbx-transaction com.alibaba.polardbx.transaction.async 异步任务相关代码，包括死锁检测、事务超时、事务日志滚动等 polardbx-transaction com.alibaba.polardbx.transaction.log 事务日志相关代码 polardbx-transaction com.alibaba.polardbx.transaction.tso TSO 服务相关代码 四、如何入手 PolarDB-X 是一个复杂的系统，代码、接口、模块众多，阅读代码需要一些技巧，推荐先整体后局部的方式。1.整体了解 和所有 SQL 数据库一样，CN 可以划分为协议层、优化器和执行器三层，阅读代码可以首先从每层的输入输出入手，了解从用户发起读写请求到收到结果的整体流程。下面简单介绍各层的一些关键接口。1)协议层 协议层实现了 MySQL 协议，负责建立连接，接收用户发送的数据包，组装成 SQL和参数传递给优化器。根据功能，协议层代码可以分为连接管理，数据包解析和协议解析三部分。连接管理和数据包解析代码在 polardbx-net 模块中，协议解析代码在 polardbx-server 模块中。PolarDB-X 源码解读（一）：CN 代码结构 11 连接管理的代码可以从建立连接入手了解，入口在 NIOAcceptor#accept。数据包解析是将数据转换为协议数据对象的过程，推荐从文本协议入手了解，入口在 AbstractConnection#read。协 议 解 析 是 将 协 议 数 据 对 象 分 发 到 具 体 执 行 逻 辑 的 过 程，入 口 在FrontendCommandHandler#handle。2)优化器 对 SQL 的处理包括语法解析，校验（Validate），生成逻辑计划，逻辑计划优化，物理计划优化五个步骤，优化产出物理执行计划，传入执行器。优化器使用了Apache Calcite 的 RBO/CBO 框架，因此优化器框架代码在 polardbx-calcite 模块中，具体实现在 polardbx-optimizer 模块中。优化器入口在 Planner#plan，以下列出各个步骤的关键接口。步骤 接口 语法解析 FastsqlParser#parse 校验 SqlConverter#validate 逻辑计划生成 SqlConverter#toRel 逻辑计划优化 Planner#optimizeBySqlWriter 物理计划优化 Planner#optimizeByPlanEnumerator 3)执行器 执行器接收到物理执行计划后，首先根据计划类型确定执行模式，包括cursor/local/mpp 三种执行模式。不同行模式下每个算子都对应的执行代码可能有差异，因此还需要将算子绑定到执行代码。执行过程会通过 RPC 接口与 DN 通信，下发读写请求并汇总结果。以下列出关键接口：步骤 接口 执行器入口 PlanExecutor#execute 执行模式选择 ExecutorHelper#execute cursor 模式算子绑定到执行代码 AbstractGroupExecutor#executeInner PolarDB-X 源码解读（一）：CN 代码结构 12 local 模式算子绑定到执行代码 LocalExecutionPlanner#plan mpp 模式切分执行计划 PlanFragmenter.Fragmenter#buildRootFragment cursor 模式与 DN 通信 MyJdbcHandler local/mpp 模式与 DN 通信 TableScanClient 2.深入了解 要深入了解模块代码，比较好的方式应该是带着问题去看。比如想要了解协议层代码，首先思考最简单的查询 select1 的处理流程是怎样的，结合前面的模块和接口介绍，跟踪调试后不难得到答案，然后继续思考其他语句/协议类型（比如 SET 和Prepared Statement）处理起来有何不同？收到/返回的包过大如何处理？SSL 如何处理？等等。另外要注意，虽然是深入了解，依然推荐在阅读过程中分清主次，“目录与模块”小节中列出的包建议重点关注，其它包中的内容则可以先快速带过。3.小结 本文主要介绍 CN（Compute Node）代码，涉及 polardbx-sql 和 polardbx-glue两个仓库，目的是帮助读者快速掌握 CN 代码的整体结构。从功能上看，CN 完成三个任务：协议处理、查询优化、与 DN 交互，代码也因此可以分为协议层、优化器、执行器三部分。文章首先介绍了代码工程的组织形式，列出编译调试相关文档。然后展开各个目录模块对应的功能，便于需要深入了解代码的读者快速定位。最后给出代码阅读建议，并列举各个模块中的关键接口，供读者调试使用。PolarDB-X 源码解读（二）：CN 启动流程 13 PolarDB-X 源码解读（二）：CN 启动流程 本文主要讲解 PolarDB-X 的 CN 节点（polardbx-sql）的启动过程包括参数加载、元信息加载等过程并对启动过程中设计的模块做简单的介绍。CN Server 层的代码主要包含在 polardbx-server 模块中，main 函数位于TddlLauncher。主逻辑入口在CobarServer.init()方法中。CN 启动分为以下几个流程：1.CobarServer 对象的创建 该类是单例，可以通过CobarServer.getInstance()获取。2.参数加载 路径：TddlLauncher.main()-CobarServer.new()-CobarConfig.new()-CobarConfig.initCobarConfig()-ServerLoader.load()CN 的参数均为 key-value 的形式。在ServerLoader.load()中，CN 主要从以下位置读取参数：server.properties 文件，其默认位置在 classpath 的根目录中，所以一般使用IDE进行开发时，加载的是polardbx-serversrcmainresourcesserver.properties 文件 String conf=System.getProperty(server.conf,classpath:server.properties);PolarDB-X 源码解读（二）：CN 启动流程 14 Java 运行参数中 例如 java.-DserverPort=8527 环境变量中 serverProps.putAll(System.getProperties();serverProps.putAll(System.getenv();以上参数来源中，server.properties 的优先级最低，环境变量中的优先级最高，当包含同名参数时，高优先级的参数来源会覆盖低优先级的参数来源。加 载 的 参 数，会 保 存 在SystemConfig中，该 类 为 单 例，可 以 通 过CobarServer.getInstance().getConfig().getSystem()获取。3.从 MetaDB 读取元数据，并初始化实例级的系统组件 路径：TddlLauncher.main()-CobarServer.new()-CobarConfig.new()-CobarConfig.initCobarConfig()-ServerLoader.load()-ServerLoader.initPolarDbXComponents()1)初始化元数据库的连接池 MetaDbDataSource.initMetaDbDataSource 会使用SystemConfig中存储的 MetaDB 的地址、端口、用户名、密码、库名等信息，建立与 MetaDB 的连接。MetaDbDataSource .initMetaDbDataSource(this.system.getMetaDbAddr(),this.system.getMetaDbName(),this.system.getMetaDbProp(),this.system.getMetaDbUser(),this.system.getMetaDbPasswd();PolarDB-X 源码解读（二）：CN 启动流程 15 MetaDbDataSource是 一 个 单 例，实 现 了JDBC的 程 序 中 可 以 使 用MetaDbDataSource.getInstance().getConnection()获取与 MetaDB 的连接（实现了 JDBC 接口），并使用该连对 MetaDB 进行访问。2)对系统表进行创建或者升级 SchemaChangeManager.getInstance().handle();polardbx-gmssrcmainresourcesddl中保存了系统表的表结构，并且使用alter 语句记录了每一次版本的变更。SchemaChangeManager 在初始化时，会检测当前每个系统表的表结构版本，如果版本较老，会依次使用这些语句对 alter 语句进行更新。3)读取实例 ID 信息 ServerInstIdManager.getInstance();一个 PolarDB-X 集群也称为一个实例，在 MetaDB 中有一个唯一的实例 ID。同时，PolarDB-X 实例有主实例与只读实例两种模式。当存在只读实例时，必然存在一个主实例。该步骤从 MetaDB 中读取实例 ID，如果当前实例为只读实例，则还会读取其主实例的实例 ID。4)MetaDbConfigManager 先简单介绍下这个东西是干啥的。我们存在 MetaDB 中的配置信息，如果发生变化，CN 需要能感知到这个变化。例如，某个表增加了一个列。作为 CN，如何能感知到这个变化呢？一个比较简单的思路是对元数据做轮询，各几秒查一次。但如果让每个模块都去做这样的事情，会有个比较大的问题是对 MetaDB 的访问压力会很大。PolarDB-X 源码解读（二）：CN 启动流程 16 MetaDbConfigManager对此作了封装，作了一个统一的轮询机制。但由于每个模块元数据表的格式千变万化，所以MetaDbConfigManager并不是直接轮询每个模块的元数据表，而是轮询 config_listener 这张表。这张表的几个关键列是 data_id、op_version、gmt_modified。我们可以为每个 data_id 在代码中注册一个 listener，当MetaDbConfigManager轮询到 data_id 的 op_version 发生变化的时，会回调这个 listener，一般情况下，各模块实现的 listener 会按需要再读取对应的元数据表。例如，d1.t1 表在 config_listener 中有一行记录：polardbx.meta.table.d1.t1 往 t1 表中增加了一个列，我们会修改 MetaDB 中的 columns 表，同时，我们会修改 config_listener 表中 polardbx.meta.table.d1.t1 这行记录的 op_version，进行+1 的操作。几秒钟后，MetaDbConfigManager会轮询到这行记录的 op_version 列发生了变化，会回调表结构管理模块的 listener（类：TableMetaListener），该 listener 会重新加载 d1.t1 表的元数据。所以MetaDbConfigManager可以做到每个 CN 节点只有一个线程对 MetaDB 做轮询就能感知到各个元数据表的变化。在启动时，CN 会初始化MetaDbConfigManager用于做轮询的线程和定时任务。5)MetaDbInstConfigManager 初始化实例级的配置项，这里的配置项类似于 MySQL 中的 System Variables，例如SQL 的内存大小限制之类的。该阶段会从 MetaDB 的 inst_config 表中加载所有的配置项并保存在内存中。PolarDB-X 源码解读（二）：CN 启动流程 17 并且会注册对应的 listener，这样当 inst_config 表发生变化的时候，会回调MetaDbInstConfigManager的 listener。6)ConnPoolConfigManager 这个是用来存连接池（CN 与 DN 之间的连接池）相关的配置项的（其实它用到的配置MetaDbInstConfigManager中都有），也是从 inst_config 中读取。7)StorageHaManager 这个比较重要。目前每一组 DN（这里的组指一个 Paxos 组）内选举的结果是存储在该组 DN 自己的系统表中，并不会写到 MetaDB 中。因此 CN 需要有机制去从 DN 的系统表中探测各节点的角色。StorageHaManager会从 storage_info 表中读取所有的 DN 节点的连接信息，并且内部会有轮询的线程去检测角色信息。当 DN 发生 HA 的时候，StorageHaManager会探测到这个变化，并感知到最新的 Leader 等角色。8)初始化系统库 initSystemDbIfNeed初始化 information_schema 和 polardbx 等几个系统库。4.创建线程池 路径：CobarServer.new()几个主要的线程池的创建：managerExecutor，负责 Manager 端口的请求 killExecutor，专门用来执行 kill 指令 PolarDB-X 源码解读（二）：CN 启动流程 18 serverExecutor，各种 SQL 都是由这个线程池执行 5.CobarServer.init 路径：TddlLauncher.main()-CobarServer.init()1)逻辑库（TDataSource）的初始化 入口在GmsAppLoader.initDbUserPrivsInfo，类里的“App”指的就是一个逻辑库。这里会加载每个逻辑库的用户权限信息以及最重要的 TDataSouce。TDataSource在 CN 中与逻辑库一一对应。它是每个逻辑库执行 SQL 的入口。TDatSource的初始化逻辑在MatrixConfigHolder.init中，包含了以下内容：初始化拓扑，例如这个库包含了哪些 DN，并初始化与这些 DN 之间的连接池（TopologyHandler.initPolarDbXTopology）获 取 每 个DN的 信 息，包 括 版 本，特 性 的 支 持 程 度 等（StorageInfoManager.init）初 始 化 分 片 的 路 由 信 息（mode=drds，TddlRuleManager.init；mode=auto，PartitionInfoManager.init）初 始 化 表 管 理 器（有 哪 些 表、每 个 表 有 哪 些 列 哪 些 索 引 等）（GmsTableMetaManager.init）初始化事务管理器（transactionManager.init()）创建 Plan Cache（PlanCache planCache=new PlanCache(schemaName);）启动 DDL 任务引擎（ddlEngineInit()）PolarDB-X 源码解读（二）：CN 启动流程 19 统计信息管理器的初始化（StatisticManager.init）SPM 的初始化（PlanManager.init）2)GmsClusterLoader.loadPolarDbXCluster 加载集群信息，例如集群中有哪些 CN 节点等。初始化CclService，这个是用来做 SQL 限流的。3)warmup CN 的 SQL 函数目前是反射机制进行加载的，这里主要作用是加载下所有的函数。6.网络层的初始化 该步骤结束后，服务端口便会打开，该 CN 进程就能开始对外提供服务了。CN 在这一步会启动 Server 端口与 Manager 端口两个端口。Server 端口对应 MySQL 的 3306 端口，是提供给前端应用使用的。Manager 端口用于内部的管理使用，例如，SHOW PROCEESSLIST 指令需要收集所有 CN 的执行情况，就会使用该端口进行收集。1)NIOProcessor processors=new NIOProcessorsystem.getProcessors();for(int i=0;i Plan Management-Validator-SQL Rewriter(RBO)-Plan Enumerator(CBO)-Mpp Planner-Post Planner七步处理，入口为 Planner#plan，以下将展开介绍各个步骤中的关键接口。四、Parser Parser 实现基于阿里巴巴开源的连接池管理软件 Druid 中的 Parser 组件，是一个手工编写的解析器，用于将 SQL 文本转换为抽象语法树（AST）。Parser 本身包含用于词法解析的 MySqlLexer 和语法解析的 MySqlStatementParser，为何这样划分超出了本文的范围，通过一个例子简单说明下。与我们阅读一句话类似，解析 SQL时首先需要 SQL 文本切分为多个“单词”（Token），比如一条简单的查询语句。SELECT*FROM t1 WHERE id 1;会被切分为如下 Token SELECT(keyword),*(identifier),FROM(keyword),t1(identifier),WHERE(keword),id(identifier),(gt),1(literal_int),;(semicolon)这个切分“单词”的过程就是词法解析。接下来，语法解析会按顺序读取所有 Token，判断是否满足某个 SQL 子句语法的同时，生成 AST，SELECT 语句结果解析生成的对象是 SqlSelect，如下图所示：PolarDB-X 源码解读（四）：SQL 的一生 43 细心的同学可能注意到了，SqlSelect 本身和其中成员变量的类型 SqlNode 都在polardbx-calcite 包而不是 polardbx-parser 包中，原因是 polardbx-sql 使用了Apache Calcite 作为优化器框架，整个框架与 AST 数据结构强绑定，因此 SQL 解析过程首先得到 Druid 的 AST 对象，然后通过一个 visitor 转换为 SqlNode。代码在FastSqlToCalciteNodeVisitor，其中也包含了一些语法改写和权限校验。另外，为了更好的支持 Plan Cache，所有 SQL 需要首先进行参数化，也就是使用占位符替换 SQL 文本中的常量参数，将 SQL 文本转换为参数化 SQL+参数列表，比如，SELECT*FROM t1 WHERE id1会被转换为SELECT*FROM t1 WHERE id?和一个参数 1，这样做的好处是相同模版不同参数的 SQL 可以命中同一条 Plan Cache，效率更高。当然也有缺点，当参数不同时整个查询的代价也不同，可能需要使用不同的计划，这个问题在 Plan Management 中得到了解决。参数化相关代码位于 PolarDB-X 源码解读（四）：SQL 的一生 44 DrdsParameterizeSqlVisitor，实现上依然是一个 visitor，返回结果封装在SqlParameterized 对象中。五、Plan Management&Plan Cache 从数据结构上讲，Plan Cache 可以认为是一个以 SQL 模版、参数信息、元数据版本等信息为 key，执行计划为 value 的一个 map。用途是减少重复优化相同 SQL 模版带来的性能开销，以及结合执行计划演进消除可能由于版本升级带来的性能回退。关于 Plan Management 的详细介绍可以参考 PolarDB-X 优化器核心技术执行计划管理。调用 Plan Cache 和 Plan Management 的逻辑封装在 Planner#d