本篇內(nèi)容主要講解“MySQL客戶端與中間件設(shè)計方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“MySQL客戶端與中間件設(shè)計方法是什么”吧!

在沁源等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作按需搭建網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,營銷型網(wǎng)站,外貿(mào)網(wǎng)站制作,沁源網(wǎng)站建設(shè)費用合理。

MySQL通信協(xié)議協(xié)議介紹

在執(zhí)行MySQL查詢，如“selecet * from test”時，MySQL的應(yīng)答包被稱為ResultSet，其為一組邏輯包(協(xié)議包)，如圖1所示包含兩個部分：

1. 元數(shù)據(jù)，包含如下數(shù)據(jù)包：      - Field_Count：列的個數(shù)      - Field：列的描述，一般為多個      - Eof：在列信息描述，或數(shù)據(jù)發(fā)送完畢時候，用以標記一段數(shù)據(jù)的發(fā)送結(jié)束。在較高版中，該數(shù)據(jù)包被取消。  2. 行數(shù)據(jù)，包含：      - Row：一行數(shù)據(jù)的內(nèi)容，多行時會出現(xiàn)多個      - Err：描述錯誤，出現(xiàn)錯誤時，為最后一個邏輯包  或      - OK：在較高版本協(xié)議中，用以替換Eof包，用以傳輸更多信息

圖1 MySQL結(jié)果集報文結(jié)構(gòu)

客戶端庫接口介紹

由此MySQL CAPI中提供了兩套函數(shù)接口：

 - mysql_store_result/mysql_stmt_store_result   - mysql_use_result  一般而言，這兩套接口的區(qū)別是：  - mysql_store_result/mysql_stmt_store_result: 將結(jié)果存儲在應(yīng)用內(nèi)存  - mysql_use_result: 數(shù)據(jù)保存在tcp buffer或數(shù)據(jù)庫server端

但從通信過程的角度來看：

- mysql_store_result/mysql_stmt_store_result: 需要等待所有數(shù)據(jù)傳輸完畢，并且客戶端解析完畢  - mysql_use_result: 簡單而言只要得到row數(shù)據(jù)包，就可以向上層api返回數(shù)據(jù)  所以，我們內(nèi)部將mysql_use_result稱為流式處理，流式處理有2大優(yōu)點：  - 應(yīng)用層響應(yīng)速度更快，因為不需要等待收齊結(jié)果集  - 內(nèi)存管理更可控，可以避免客戶端內(nèi)存不足

在mysql客戶端以及mysqldump命令中，有如下參數(shù)：

- --quik/-q，即使用mysql_use_result，進行流式處理，可以避免mysqldump大數(shù)據(jù)量下oom

JDBC在設(shè)計上封裝性更高，一般而言其邏輯與CAPI的

mysql_store_result/mysql_stmt_store_result處理邏輯一樣，但有2個方法可以將其轉(zhuǎn)換為流式處理模式：  - 代碼層面：prepareStatement第2、3個參數(shù)設(shè)置為ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY  - JDBC URL設(shè)置(不修改代碼)：增加參數(shù)useCursorFetch=true&defaultFetchSize=-2147483648 (該方法在不同版本的jdbc驅(qū)動上表現(xiàn)有區(qū)別，不建議采用)

API與協(xié)議解析的關(guān)系圖2所示：

▲ 圖2 API與協(xié)議解析

UPSQL Proxy中間件設(shè)計

在UPSQL Proxy 2.4.0以前使用的是阻塞模式，即往多個后端收齊結(jié)果集后，再向用戶應(yīng)答，這樣有2個缺點：-

響應(yīng)時延延長  Proxy層內(nèi)存控制，導(dǎo)致生產(chǎn)環(huán)境不支持大于分庫下10w行以上數(shù)據(jù)量返回

UPSQL Proxy 2.4.0實現(xiàn)了流式處理，簡單而言就是，將行信息盡快以流的形式發(fā)給客戶端而不是等中間件收齊后發(fā)送，邏輯如圖3所示：

▲ 圖3 UPSQL Proxy的流式處理

即在分庫場景下，會并發(fā)訪問各個數(shù)據(jù)節(jié)點，當(dāng)?shù)玫揭粋€完整的元數(shù)據(jù)后，就可以立刻返回給請求方，之后接收到行數(shù)據(jù)后，都可以及時的返回給請求方，以此降低中間件的內(nèi)存需求，同時提高客戶端的相應(yīng)速度。

到此，相信大家對“MySQL客戶端與中間件設(shè)計方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！