一、前言
一年前的《彩虹桥架构演进之路》侧重探讨了稳定性和功能性两个方向。在过去一年中，尽管业务需求不断增长且流量激增了数倍，彩虹桥仍保持着零故障的一个状态，算是不错的阶段性成果。而这次的架构演进，主要分享一下近期针对性能层面做的一些架构调整和优化。其中最大的调整就是 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）方式连接数据库。
三、改造后的架构
想把 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 官方文档中鉴权流程和命令执行流程：
下面就是按照 MySQL 的文档，去实现编解码 Handle，我们简单看一下实现的代码。 ![]()
就是针对 MySQL 返回的数据包解码，根据长度解析出 Palyload 封装成 MySQLPacketPayload 传给对应的 Handle 处理。
把具体的命令类转换成具体的 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 线程中处理。 ![]()
具体的做法就是 Backend 在选择与数据库连接时，优先选择与当前 EventLoop 绑定的连接。也就是前面提到的 EventLoop 亲和性，这样就能保证大部分场景下一次请求从头到尾都由同一个 EventLoop 处理，下面我们看一下具体的代码实现。
在 NettyDbConnectionPool 类中使用一个 Map 存储连接池中的空闲连接，Key 为 EventLoop，Value 为当前 EventLoop 绑定的空闲连接队列。 ![]()
在获取时，优先获取当前 EventLoop 绑定的连接，如果当前 EventLoop 未绑定连接，则会借用其他 EventLoop 的连接。 ![]()
为了提高 EventLoop 命中率，需要注意几点配置：
- EventLoop 线程数量尽量与 CPU 核心数保持一致。
- 连接池最大连接数超过 EventLoop 线程数越多，EventLoop 命中率越高。
下面放一张压测环境（8C16G、连接池最大连接数 10~30）的命中率监控，大部分保持在 75% 左右。 ![]()
跳过不必要的编解码
前面说到，有部分 SQL 的结果集是不需要 Proxy 进行加工的，也就是可以直接把 MySQL 返回的数据流原封不动转发给上游，直接省去编解码操作。那什么 SQL 是不需要 Proxy 进行加工的呢，我们举个例子说明一下。
假设逻辑库 A 里面有一张表 User 做了分库，分了 2 个库 DB1 和 DB2，分片算法是 user_id%2。
SELECT id, name FROM user WHERE user_id in (1, 2)
SELECT id, name FROM user WHERE user_id in (1)
很显然 SQL 1由于有 2 个分片 Value，最终匹配到了 2 个节点，SQL 2 只会匹配到 1 个节点。 ![]()
SQL 1 由于需要对结果集进行归并，所以无法跳过编解码，SQL 2 不需要对结果集归并，只需要把结果集中的列定义数据做修正后，真正的 Row 数据无需处理，这种情况就可以把 Row 数据直接转发至上游。
全链路异步化
Backend 层用自研连接池+驱动替换原先的 HikariCP+JDBC 后，从 Frontend-Core-Backend 全链路涉及到阻塞的操作需要全部替换成异步化编码，也就是通过 Netty 的 Promise 和 Future 来实现。 ![]()
由于部分场景拿到 Future 时，可能当前 Future 已经完成了，如果每次都是无脑的加 Listener 会让调用栈加长，所以我们定义了一个通用的工具类来处理 Future，即 future.isDone() 时直接执行，反之才会 addListener，最大化降低整个调用栈的深度。 ![]()
兼容性
除了以上基本代码的改造外，还需要做大量的兼容工作：
- 特殊数据库字段类型处理
- JDBC URL 参数兼容
- ThreadLocal 相关数据全部需要迁移至 ChannelHandlerContext 中
- 日志 MDC、TraceContext 相关数据传递
- ……
四、性能表现
经过几轮性能压测后，NIO架构相较于BIO架构性能有较大提升：
- 整体最大吞吐量提升 67%
- LOAD 下降 37% 左右
- 高负载情况下 BIO 多次出现进程夯住现象，NIO 相对较稳定
- 线程数减少 98% 左右
五、总结
NIO 架构的改造工作量相当巨大，中间也经历了一些曲折，但是最终的结果令人满意。得益于 ShardingShpere 本身内核层面的高性能加上本次 NIO 改造后，彩虹桥在 DAL 中间件性能层面基本上可以算是第一梯队了。
*文 / 新一
本文属得物技术原创，更多精彩文章请看：得物技术官网
未经得物技术许可严禁转载，否则依法追究法律责任！
看起来比较简单，交互流程和传统的 JDBC 几乎一样，但是由于现在是异步化流程，所有的 Response 都是通过回调返回，所以这里有 2 个难点：
