彩虹桥架构演进之路-性能篇-编程知识

一、前言

一年前的《彩虹桥架构演进之路》侧重探讨了稳定性和功能性两个方向。在过去一年中，尽管业务需求不断增长且流量激增了数倍，彩虹桥仍保持着零故障的一个状态，算是不错的阶段性成果。而这次的架构演进，主要分享一下近期针对性能层面做的一些架构调整和优化。其中最大的调整就是 Proxy-DB 层的线程模式从 BIO 改造成了性能更好的 NIO。下面会详细介绍一下具体的改造细节以及做了哪些优化。

阅读本文预计需要 20～30 分钟，整体内容会有些枯燥难懂，建议阅读前先看一下上一篇彩虹桥架构演进的文章（彩虹桥架构演进之路）以及 MySQL 协议相关基础知识。

二、改造前的架构

先来复习一下彩虹桥的全景架构图：

Proxy三层模块

针对 Proxy 这一层，可以大致分成 Frontend、Core、Backend 三层：

Frontend-服务暴露层：使用 Netty 作为服务器，按照 MySQL 协议对接收&返回的数据进行编解码。
Core-功能&内核层：通过解析、改写、路由等内核能力实现数据分片、读写分离、影子库路由等核心功能。
Backend-底层DB交互层：通过 JDBC 实现与数据库交互、对结果集改列、归并等操作。

BIO模式下的问题

这里 Core 层为纯计算操作，而 Frontend、Backend 都涉及 IO 操作，Frontend 层使用 Netty 暴露服务为 NIO 模式，但是 Backend 使用了数据库厂商提供的传统 JDBC 驱动，为 BIO 模式。所以 Proxy 的整体架构还是 BIO 模式。在 BIO 模型中，每个连接都需要一个独立的线程来处理。这种模型有一些明显的缺点：

高资源消耗：每个请求创建独立线程，伴随大量线程开销。线程切换与调度额外消耗 CPU。
扩展性受限：受系统线程上限影响，处理大量并发连接时，性能急剧下降。
I/O阻塞：BIO 模型中，读/写操作均为阻塞型，导致线程无法执行其他任务，造成资源浪费。
复杂的线程管理：线程管理和同步问题增加开发和维护难度。

我们看最简单的一个场景：在 JDBC 在发起请求后，当前线程会一直阻塞直到数据库返回数据，当出现大量慢查或者数据库出现故障时，会导致大量线程阻塞，最终雪崩。在上一篇彩虹桥架构演进文章中，我们做了一些改进来避免了 BIO 模型下的一些问题，比如使用线程池隔离来解决单库阻塞导致全局雪崩的问题。

但是随着逻辑库数量的增多，最终导致 Proxy 的线程数膨胀。系统的可伸缩性和吞吐量都受到了挑战。因此有必要将现有的基于 JDBC 驱动的阻塞式连接升级为采用 NIO（非阻塞 I/O）方式连接数据库。

三、改造后的架构

BIO->NIO

想把 Proxy 整体架构从 BIO->NIO，最简单的方式就是把传统的 BIO 数据库驱动 JDBC 换成 NIO 的数据库驱动，但是在调研过后发现开源的 NIO 驱动并不多，而且基本上没有什么最佳实践。最后在参考 ShardingSphere 社区之前做的调研后（https://github.com/apache/shardingsphere/issues/13957），决定使用 Vertx 来替换 JDBC。最开始使用 Vert.x 的原因，第一是 Vertx 的异步编码方式更友好，编码复杂度相对较低，第二是因为它实现了主流数据库的驱动。但最终的结果不尽人意，由于 Vertx 相关抽象化的架构，导致链路较长时，整个调用栈深非常夸张。最终压测出来的吞吐量提升只有 5% 不到，而且存在很多兼容性问题。于是推倒重来，决定自研数据库驱动和连接池。

跳过不必要的编解码阶段

由于 JDBC 驱动会自动把 MySQL 的字节数据编解码成 Java 对象，然后 Proxy 再把这些结果集经过一些加工（元信息修正、结果集归并）后再进行编码返回给上游。如果自研驱动的话，就可以把编解码流程控制的更细致一些，把 Proxy 不需要加工的数据直接转发给上游，跳过无意义的编解码。后面会介绍一下哪些场景是不需要 Proxy 对结果集进行加工的。

自研NIO数据库驱动

数据库驱动主要是封装了与 DB 层交互协议，封装成高级 API。下面 2 张图是 java.sql 包中的 Connection 和 Statement 的一些核心接口。

所以首先我们需要了解一下，如何与数据库进行数据交互，以 MySQL 为例，使用 Netty 连接 MySQL，简单的交互流程如下。

使用 Netty 与 MySQL 连接建立后，我们要做的就是按照 MySQL 协议规定的数据格式，先鉴权后再发送具体的命令包即可。下面是 MySQL 官方文档中鉴权流程和命令执行流程：

鉴权流程：https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase.html
执行命令流程：https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_command_phase.html

下面就是按照 MySQL 的文档，去实现编解码 Handle，我们简单看一下实现的代码。

decode 解码

就是针对 MySQL 返回的数据包解码，根据长度解析出 Palyload 封装成 MySQLPacketPayload 传给对应的 Handle 处理。

encode 编码

把具体的命令类转换成具体的 MySQL 数据包，这里的 MySQLPacket 有多个实现类，跟 MySQL的Command 类型一一对应。

现在还需要一个类似 java.sql.Connection 的实现类，来组装 MySQLPacket 并写入到 Netty 通道中，并且解析编码后的 MySQLPacketPayload 转换成 ResultSet。

看起来比较简单，交互流程和传统的 JDBC 几乎一样，但是由于现在是异步化流程，所有的 Response 都是通过回调返回，所以这里有 2 个难点：

由于 MySQL 在上一条命令没结束前无法接受新的命令，所以如何控制单个连接的命令串行化？
如何将 MySQL 返回的数据包和发起命令的 Request 一一绑定？

首先 NettyDbConnection 引入了一个无锁化非阻塞队列 ConcurrentLinkedQueue。

在发送 Command 时，如何没有正在进行中的 Command，则直接发送，如果有正在进行中的 Command，直接扔到队列中，等待上一条 Command 处理完成后推动下一条命令的执行。保证了单个连接命令串行化。

其次，NettyDbConnection 在执行命令时，传入一个 Promise，在 MySQL 数据包全部返回后，这个 Promise 将会被设置完成，即可于发起命令的 Request 一一绑定。

自研NIO数据库连接池

前面介绍了 NettyDbConnection 这个类，实现了与 MySQL 的交互，并且提供了执行 SQL 的高级 API，但实际使用过程中，不可能每次都创建一个连接执行完 SQL 就关闭。所以需要对 NettyDbConnection 进行池化，统一管理连接的生命周期。其功能类似于传统连接池 HikariCP，在完成基本能力的基础上，做了很多性能优化。

连接生命周期管控
连接池动态伸缩
完善的监控
连接异步保活
超时控制
EventLoop 亲和性

这里除了 EventLoop 亲和性，其他几个功能只要用过传统的数据库连接池应该都比较熟悉，这里不做过多展开。这里主要针对 EventLoop 亲和性展开介绍一下。

在文章开头我们说到 Proxy 的三层模块，Frontend、Core、Backend，如果现在我们把 Backend 层于数据库交互的组件换成了我们自研的驱动，那么 Proxy 就即是Netty Server，也是Netty Client，所以 Frontend 和 Backend 可以共用一个 EventLoopGroup。为了降低线程上下文切换，在单个请求从 Frontend 接收、经过 Core 层计算后转发到 MySQL ，再到接收 MySQL 服务响应，以及最终的回写给 Client 端，这一些列操作尽量放在一个 EventLoop 线程中处理。