原创 周家晶

作者简介:周家晶,中国银联·云计算中心。作者长期负责中国银联自研中间件UPSQL Proxy和分布式数据库UPDRDB的研发与设计工作。


本文以UPSQL Proxy 2.4.0中关键的报文流式处理为例,介绍MySQL通信协议,以及与客户端的关系。


MySQL通信协议协议介绍
在执行MySQL查询,如“selecet * from test”时,MySQL的应答包被称为ResultSet,其为一组逻辑包(协议包),如图1所示包含两个部分:


1. 元数据,包含如下数据包:
    - Field_Count:列的个数
    - Field:列的描述,一般为多个
    - Eof:在列信息描述,或数据发送完毕时候,用以标记一段数据的发送结束。在较高版中,该数据包被取消。
2. 行数据,包含:
    - Row:一行数据的内容,多行时会出现多个
    - Err:描述错误,出现错误时,为最后一个逻辑包
    - OK:在较高版本协议中,用以替换Eof包,用以传输更多信息


图1 MySQL结果集报文结构

客户端库接口介绍

由此MySQL CAPI中提供了两套函数接口:


 - mysql_store_result/mysql_stmt_store_result
 - mysql_use_result
一般而言,这两套接口的区别是:
- mysql_store_result/mysql_stmt_store_result: 将结果存储在应用内存
- mysql_use_result: 数据保存在tcp buffer或数据库server端

但从通信过程的角度来看:


- mysql_store_result/mysql_stmt_store_result: 需要等待所有数据传输完毕,并且客户端解析完毕
- mysql_use_result: 简单而言只要得到row数据包,就可以向上层api返回数据
所以,我们内部将mysql_use_result称为流式处理,流式处理有2大优点:
- 应用层响应速度更快,因为不需要等待收齐结果集
- 内存管理更可控,可以避免客户端内存不足

在mysql客户端以及mysqldump命令中,有如下参数:


    - --quik/-q,即使用mysql_use_result,进行流式处理,可以避免mysqldump大数据量下oom


JDBC在设计上封装性更高,一般而言其逻辑与CAPI的

mysql_store_result/mysql_stmt_store_result处理逻辑一样,但有2个方法可以将其转换为流式处理模式:


- 代码层面:prepareStatement第2、3个参数设置为ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY

- JDBC URL设置(不修改代码):增加参数useCursorFetch=true&defaultFetchSize=-2147483648 (该方法在不同版本的jdbc驱动上表现有区别,不建议采用)


API与协议解析的关系图2所示:

▲ 图2 API与协议解析



UPSQL Proxy中间件设计

在UPSQL Proxy 2.4.0以前使用的是阻塞模式,即往多个后端收齐结果集后,再向用户应答,这样有2个缺点:


- 响应时延延长
- Proxy层内存控制,导致生产环境不支持大于分库下10w行以上数据量返回

UPSQL Proxy 2.4.0实现了流式处理,简单而言就是,将行信息尽快以流的形式发给客户端而不是等中间件收齐后发送,逻辑如图3所示:
 
▲ 图3 UPSQL Proxy的流式处理

即在分库场景下,会并发访问各个数据节点,当得到一个完整的元数据后,就可以立刻返回给请求方,之后接收到行数据后,都可以及时的返回给请求方,以此降低中间件的内存需求,同时提高客户端的相应速度。



总结


本文介绍了银联自研中间件UPSQL Proxy早前的一次关键功能迭代,希望能让大家感受到MySQL协议的魅力。