MySQL客户端与中间件设计方法是什么

本篇内容主要讲解“Mysql客户端与中间件设计方法是什么”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“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的流式处理

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

到此，相信大家对“MySQL客户端与中间件设计方法是什么”有了更深的了解，不妨来实际操作一番吧！这里是编程网网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！