## 一、前言

**背景**

在 Database Mesh 中，Pisanix 是一套以資料庫為中心的治理框架，為使用者提供了諸多治理能力，例如：資料庫流量治理，SQL 防火牆，負載均衡和審計等。在 Pisanix 中，Pisa-Proxy 是作為整個 Database Mesh 實現中資料平面的核心元件。Pisa-Proxy 服務本身需要具備 MySQL 協議感知，理解 SQL 語句，能對後端代理的資料庫做一些特定的策略，SQL 併發控制和斷路等功能。在這諸多特性當中，能夠理解 MySQL 協議就尤為重要，本篇將主要介紹 MySQL 協議和在 Pisa-Proxy 中 MySQL 協議的 Rust 實現。

**Why Rust**

為什麼要選用 Rust 語言呢？我們的考量有以下幾個必要條件。

* 安全性：首先作為資料庫治理的核心元件，其語言的安全性是居首位的。Rust 中，型別安全實現記憶體安全，如所有權機制、借用、生命週期等特性避免了程式開發過程中的空指標、懸垂指標等問題，從而保證了服務在語言層面的安全性。

* 優秀的效能表現：Rust 的目標在效能方面對標 C 語言，但在安全和生產力方面則比 C 更勝一籌。其無 GC，不需要開發人員手動分配記憶體等特性，極大程度地減少記憶體碎片，簡化記憶體管理。

* 低開銷：從開發效率和可讀可維護性上來說，有足夠的抽象能力，並且這種抽象沒有執行時開銷（runtime cost）。零開銷抽象，透過泛型和 Trait 在編譯期展開並完成抽象解釋。

* 實用性：有優秀的包管理器工具 Crate、文件註釋支援、詳細的編譯器提示、友好的錯誤處理等，在開發過程中能夠高效幫助程式設計師快速開發出可靠、高效能的應用。

## 二、整體架構，模組設計

整體架構
如圖 1，代理服務包含服務端和客戶端的協議解析、SQL 解析、訪問控制、連線池等模組。
![](http://img.blog.itpub.net/blog/2022/06/17/6b2fa93eb9fc5343.png?x-oss-process=style/bb)

**工作流程**
在圖 1 中我們可以看出整個 Proxy 服務可以概括為以下幾個階段。

1. 首先 Pisa-Proxy 支援 MySQL 協議，將自己偽裝為資料庫服務端，應用連線配置只需修改訪問地址即可建連 Pisa-Proxy 透過讀取應用發來的握手請求和資料包；

2. 得到應用發來的 SQL 語句後對該 SQL 進行語法解析，並得到該 SQL 的 AST；

3. 得到對應 AST 後，基於 AST 實現高階訪問控制和 SQL 防火牆能力；

4. 訪問控制和防火牆透過後 SQL 提交執行，SQL 執行階段的指標將採集為 Prometheus Metrics，最後根據負載均衡策略獲取執行該語句的後端資料庫連線；

5. 如果連線池為空將根據配置建立和後端資料庫的連線，SQL 將從該連線發往後端資料庫；

6. 最後讀取 SQL 執行結果，組裝後返回給客戶端。

## 三、如何用 Rust 快速實現 MySQL 代理服務

如圖 2，在整個代理服務中總體分為兩部分：服務端和客戶端，即代理服務作為服務端處理來自客戶端的請求。和服務端，需要對服務端發起認證，並將客戶端端命令傳送給 MySQL 資料庫。在這兩部分中我們需要建立兩套 Socket 來完成網路資料包的處理。

![](http://img.blog.itpub.net/blog/2022/06/17/462ea8f5974ad78c.png?x-oss-process=style/bb)

**技術選型**

> 介紹

在網路報處理和執行時處理上，我們選用了 Rust 實現的 Tokio（ https://github.com/tokio-rs/tokio ）框架。Tokio 框架是 Rust 編寫的可靠、非同步和精簡應用程式的執行時。並且 Tokio 是一個事件驅動的非阻塞 I/O 平臺，用於使用 Rust 程式語言編寫非同步應用程式。在高層次上，它提供了幾個主要元件：

* 一個多執行緒、基於工作竊取的任務排程程式（https://docs.rs/tokio/latest/tokio/runtime/index.html ）。

* 由作業系統的事件佇列（epoll、kqueue、IOCP 等）支援的響應式程式設計。

* 非同步 TCP 和 UDP（https://docs.rs/tokio/latest/tokio/net/index.html ）套接字。

同時，Tokio 還提供了豐富的工具鏈，例如編解碼工具包、分幀包等等，可以使我們更加方便快捷地處理 MySQL 中各種各樣的資料包文。

專案地址: https://github.com/tokio-rs/tokio

> 優勢

a. 快速：Tokio 的設計旨在使應用程式儘可能都快。

b. 零成本抽象：Tokio 以 Future 為基礎。雖然 Future 並非 Rust 獨創，但與其他語言的 Future 不同的是，Tokio Future 編譯成了狀態機，用 Future 實現常見的同步，不會增加額外開銷成本。Tokio 的非阻塞 IO 可以充分發揮系統優勢，例如實現類似 Linux Epoll 這種多路複用技術，在單個執行緒上的多路複用允許套接字並批次接收作業系統訊息，從而減少系統呼叫，所有這些都可以減少應用程式的開銷。

c. 可靠：Rust 的所有權模型和型別系統可以實現系統級應用程式，而不必擔心記憶體不安全。

d. 輕量級：沒有垃圾收集器，因為 Tokio 是基於 Rust 構建的，所以編譯後的可執行檔案包含最少的語言執行時。這意味著，沒有垃圾收集器，沒有虛擬機器，沒有 JIT 編譯，也沒有堆疊操作。這樣在編寫多執行緒併發的系統時，能夠有效避免阻塞。

e. 模組化：每個元件都位於一個單獨的庫中。如果需要，應用程式可以挑選所需的元件，避免依賴不需要的元件。

**程式碼實現**
> Rust 中資料包處理

```
#[derive(Debug)]
pub struct Packet {
    pub sequence: u8,
    pub conn: BufStream<localstream>,
    pub header: [u8; 4],
}
```

以上為 Proxy 資料包處理邏輯中核心的結構體，結構體中包含了三個欄位分別為：

* sequence：報文中的序列號 ID

* conn：處理連結的 Socket

* header：儲存訊息頭報文的陣列，長度為 4 位元組

在包處理邏輯中主要定義了以下函式，在整個代理服務中網路資料交換都由以下方法來完成。

> Pisa-Proxy 作為服務端

```
pub struct Connection {
    salt: Vec<u8>,
    status: u16,
    collation: CollationId,
    capability: u32,
    connection_id: u32,
    _charset: String,
    user: String,
    password: String,
    auth_data: BytesMut,
    pub auth_plugin_name: String,
    pub db: String,
    pub affected_rows: i64,
    pub pkt: Packet,
}
```
上面的結構體描述了 Pisa- Proxy 作為服務端處理來自於客戶端請求時所包含的欄位。例如，其中包含了和 MySQL 客戶端進行認證資訊，和所包含資料包處理邏輯的 Packet。

> Pisa-Proxy 作為客戶端

```
#[derive(Debug, Default)]
pub struct ClientConn {
    pub framed: Option<box>>,
    pub auth_info: Option<clientauth>,
    user: String,
    password: String,
    endpoint: String,
}
```

> Tokio 提供的編解碼器

在 Pisa-Proxy 中，大量使用了 Tokio 工具包中的編解碼器，使用 codec Rust 會自動幫助開發者將原始位元組轉化為 Rust 的資料型別，方便開發者處理資料。使用編解碼器，只需要在程式碼中為定義好的型別實現 Decoder 和 Encoder 兩個 Trait，就可以透過 stream 和 sink 進行資料的讀寫。下面透過一個簡單的示例來看一下 Tokio 編解碼器的使用步驟。

使用 Tokio 編解碼器一共分為三步：

1. 首先要自定義一個錯誤型別，這裡定義了一個 ProtocolError，併為它實現一個 from 方法，能夠讓它接收錯誤處理。

```
pub enum ProtocolError {
    Io(io::Error),
}

impl From<:error> for ProtocolError {
    fn from(err: io::Error) -> Self {
        ProtocolError::Io(err)
    }
}
```
2. 定義一個資料型別，這裡我們宣告一個 Message 為 String，然後定義一個結構體，也就是我們要解析的是原始位元組流要實際轉換成的結構體，也即 Tokio 中 framed（幀的概念），這裡定義一個空結構體 PisaProxy；

```
type Message = String;
struct PisaProxy;
```

接下來就是為 PisaProxy 分別實現 Encoder 和 Decoder 這兩個 Trait。這裡的示例，實現的功能為將資料轉為 byte 陣列，追加到 buf 中。在編碼器中，我們首先要指定 Item 型別為 Message 和錯誤型別，編碼處理邏輯這裡將字串進行拼接並返回給客戶端。

在這裡，Encoder 編碼是指將使用者自定義型別轉換成 BytesMut 型別，寫到 TcpStream 中，Decoder 解碼指將讀到的位元組資料序列化為 Rust 的結構體。

```
impl Encoder<message> for PisaProxy {
    type Error = ProtocolError;

fn encode(&mut self, item: Message, dst: &mut BytesMut) ->Result {
        dst.extend(item.as_bytes());
        Ok(())
    }
}

impl Decoder for PisaProxy {
    type Item = Message;
    type Error = ProtocolError;

fn decode(&mut self, src: &mut BytesMut) -> Result<option>, Self::Error> {
        if src.is_empty() {
            return Ok(None);
        }
        let data = src.split();
        let mut buf = BytesMut::from(&b"hello:"[..]);
        buf.extend_from_slice(&data[..]);
        let data = String::from_utf8_lossy(&buf[..]).to_string();

Ok(Some(data))
    }
}
```

3. 當例項化 PisaProxy 結構體後，就可以呼叫 framed 方法，codec 的 framed 方法（codec.framed(socket)）將 TcpStream 轉換為 Framed<tcpstream>，這個 Framed 就是實現了 tokio 中的 Stream 和 Sink 這兩個 trait，實現的這兩個 Trait 的例項就具有了接收（透過 Stream）和傳送（透過 Sink）資料的功能，這樣我們就可以呼叫 send 方法傳送資料了。

```
#[tokio::main]
async fn main() -> Result> {
    let addr = "127.0.0.1:9088";
    let listener = TcpListener::bind(addr).await?;
    println!("listen on: {:?}", addr);

loop {
        let (socket, addr) = listener.accept().await?;

println!("accepted connect from: {}", addr);

tokio::spawn(async move {
            let codec = PisaProxy {};
            let mut conn = codec.framed(socket);
            loop {
                match conn.next().await {
                    Some(Ok(None)) => println("waiting for data..."),
                    Some(Ok(data)) => {
                        println!("data {:?}", data);
                        conn.send(data).await;
                    },
                    Some(Err(e)) => {
                    },
                    None => {},
                }
            }
        });
    }
}
```

## 四、MySQL 協議在 Pisa-Proxy 中的實現

MySQL 協議簡介
MySQL 資料庫本身是一個很典型的 C/S 結構的服務，客戶端和服務端通訊可以透過 Tcp 和 Unix Socket 的方式進行互動。在本篇中，我們主要說明透過網路 Tcp 的方式來實現 MySQL 代理。

MySQL 客戶端和服務端的互動主要包含了兩個重要的過程：1. 握手認證，2.傳送命令。本篇會主要圍繞這兩個過程來介紹相關的實現。在客戶端和服務端互動的過程中主要包含了以下幾種型別報文：資料包、資料結束包、成功報告包以及錯誤訊息包，在後面的章節中會為大家詳細介紹這幾種報文。

**互動過程**
MySQL 客戶端和服務端在互動的過程中主要包含了兩個過程，即握手認證階段和執行命令階段，當然在這兩個過程之前首先要經歷 TCP 三次握手的過程。在三次握手結束後首先進入握手認證階段，在交換完資訊並且客戶端正確登入服務端後，進入執行命令階段，圖 3 完整描述了整個互動過程。

程式碼連結：https://github.com/database-mesh/pisanix/blob/master/pisa-proxy/protocol/mysql/src/server/conn.rs
![](http://img.blog.itpub.net/blog/2022/06/17/b3322eec6c75b2f7.png?x-oss-process=style/bb)

> 握手認證

在握手認證階段是 MySQL 客戶端和服務端建聯非常重要的階段，該階段發生在 TCP 三次握手之後。首先服務端會給客戶端傳送服務端資訊，其中包括協議版本號、服務版本資訊、挑戰隨機數、權能標誌位等等。當客戶端接收到服務端發來的響應之後，客戶端開始發起認證請求。認證請求中，會攜帶客戶端使用者名稱、資料庫名以及透過服務端響應中的挑戰隨機數將客戶端密碼加密後，一同傳送給服務端進行校驗。校驗過程中，除了會對使用者名稱密碼進行校驗，還會匹配客戶端所使用的認證外掛，如果不匹配則會發生外掛的自動切換，以及判斷客戶端是否使用了加密連結。當以上階段全部正常完成後，客戶端則登入成功，服務端返回客戶端 OK 資料包文。

上述過程分別在 runtime 和 protocol 的 server 中實現。在 runtime 中的 start 函式等待請求進入，Tcp 三次握手結束後，從 `handshake` 函式如圖 3，開始握手階段。在 handshake 中分別包含了三個過程，首先由 `write_initial_handshake` 給客戶端傳送服務端資訊，然後在 `read_handshake_response` 客戶端拿著服務端資訊開始認證請求。

```
pub async fn handshake(&mut self) -> Result {
        match self.write_initial_handshake().await {
            Err(err) => return Err(err::ProtocolError::Io(err)),
            Ok(_) => debug!("it is ok"),
        }

match self.read_handshake_response().await {
            Err(err) => {
                return Err(err);
            }
            Ok(_) => {
                self.pkt.write_ok().await?;
                debug!("handshake response ok")
            }
        }

self.pkt.sequence = 0;

Ok(())
    }
```

> 執行命令

當握手和認證階段完成後，此時客戶端才算是真正意義上的與服務端完成建立連結。那麼此時則進入執行命令階段。在 MySQL 中，能夠傳送命令的指令型別有很多種，我們會在下文中為大家進行介紹。

程式碼連結: https://github.com/database-mesh/pisanix/blob/master/pisa-proxy/runtime/mysql/src/server/server.rs

在下面的程式碼中可以看到，Pisa-Proxy 在這裡會對不同型別的指令進行不同的邏輯處理。例如，初始化 db 的處理邏輯為 `handle_init_db`，處理查詢的邏輯為 `handle_query`。

```
match cmd {
            COM_INIT_DB => self.handle_init_db(&payload, true).await,
            COM_QUERY => self.handle_query(&payload).await,
            COM_FIELD_LIST => self.handle_field_list(&payload).await,
            COM_QUIT => self.handle_quit().await,
            COM_PING => self.handle_ok().await,
            COM_STMT_PREPARE => self.handle_prepare(&payload).await,
            COM_STMT_EXECUTE => self.handle_execute(&payload).await,
            COM_STMT_CLOSE => self.handle_stmt_close(&payload).await,
            COM_STMT_RESET => self.handle_ok().await,
            _ => self.handle_err(format!("command {} not support", cmd)).await,
}

```
**MySQL 協議基本資料型別**
在 MySQL 協議中主要有以下幾種資料型別：

* 整型值：MySQL 報文中整型值分別有 1、2、3、4、8 位元組長度，使用小端傳輸。

* 字串（以 NULL 結尾）（Null-Terminated String）：字串長度不固定，當遇到'NULL'（0x00）字元時結束。

* 二進位制資料（長度編碼）（Length Coded Binary）

參考連結：https://dev.mysql.com/doc/internals/en/basic-types.html

**報文結構**
在 MySQL 客戶端和服務端所互動的資料最大長度為 16MByte，其基本資料包文結構型別如下：

![](http://img.blog.itpub.net/blog/2022/06/17/a2b1203f9b77bf73.png?x-oss-process=style/bb)

圖 4
![](http://img.blog.itpub.net/blog/2022/06/17/0f80cf2e323f0b15.png?x-oss-process=style/bb)

圖 5

在圖 4 和圖 5 中描述了 MySQL 報文的基本結構。報文包括了兩部分，訊息頭和訊息體。其中在訊息頭中，3 位元組表示資料包文長度，1 位元組儲存序列號，訊息體中儲存實際的報文資料。

> 訊息頭

用於標記當前請求訊息的實際資料長度值，以位元組為單位，佔用 3 個位元組，最大值為 0xFFFFFF，即接 2^24-1。

> 序列號

序列 ID 從 0 開始隨每個資料包遞增，並且當進入新的命令時重置為 0。序列號 ID 有可能會發生迴繞，當發生迴繞時，需將序列號 ID 重置為 0，並且重新開始計數遞增。

> 報文資料

訊息體用於存放請求的內容及響應的資料，長度由訊息頭中的長度值決定。

> 客戶端請求命令報文

該指令用於標識客戶所要執行命令的型別，以位元組為單位佔用 1 個位元組。請求命令報文常用到的有 Text 文字協議和 Binary 二進位制協議。這裡可以參考【執行命令】中的程式碼，程式碼中描述了對不同指令的處理邏輯。

在文字協議中常用到的有以下指令：

| 值 | 指令 | 功能 |
| ----- | ----- |----- |
| 0x01 | COM_QUIT | 關閉連線 |
| 0x02 | COM_INIT_DB | 切換資料庫 |
| 0x03 | COM_QUERY | SQL 查詢請求 |
| 0x04 | COM_FIELD_LIST | 獲取資料表欄位資訊|
| 0x05 | COM_CREATE_DB | 建立資料庫 |
| 0x06 | COM_DROP_DB | 刪除資料庫 |
| 0x08 | COM_SHUTDOWN | 停止伺服器 |
| 0x0A | COM_PROCESS_INFO | 獲取當前連線的列表 |
| 0x0B | COM_CONNECT | （內部執行緒狀態） |
| 0x0E | COM_PING | 測試連通性 |

更多請參考：https://dev.mysql.com/doc/internals/en/text-protocol.html

在二進位制協議，即 Prepare Statement 中常用到的有以下指令：

| 值 | 指令 | 功能 |
| ----- | ----- |----- |
| 0x16 | COM_STMT_PREPARE | 預處理 SQL 語句 |
| 0x17 | COM_STMT_EXECUTE | 執行預處理語句 |
| 0x18 | CCOM_STMT_SEND_LONG_DATA | 傳送 BLOB 型別的資料 |
| 0x19 | COM_STMT_CLOSE | 銷燬預處理語句|
| 0x1A | COM_STMT_RESET | 清除預處理語句引數快取 |

更多請參考：https://dev.mysql.com/doc/internals/en/prepared-statements.html

響應報文
* OK 響應報文

* Error 響應報文

* Field 結構

* EOF 結構

* Row Data 結構

......

例如，下面程式碼中展示瞭如何給客戶端寫 OK 和 EOF 報文。

```
#[inline]
pub async fn write_ok(&mut self) -> Result {
    let mut data = [7, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0];
    self.set_seq_id(&mut data);
    self.write_buf(&data).await
}
    
#[inline]
pub async fn write_eof(&mut self) -> Result {
    let mut eof = [5, 0, 0, 0, 0xfe, 0, 0, 2, 0];
    self.set_seq_id(&mut eof);
    self.write_buf(&eof).await
}
```

> com_query 請求流程

如圖 6 為 com_query 的請求流程，com_query 指令可能會返回以下結果集：

* ERR 報文

* OK 報文

* Protocol::LOCAL_INFILE_Request 報文

* Resultset 報文

在 ( https://github.com/database-mesh/pisanix/blob/master/pisa-proxy/protocol/mysql/src/client/resultset.rs ) 檔案中主要為對 ResultSet 結果集的處理，可以看到在這裡定義了 ResultSet 結構，同樣對 ResultSetCodec 分別實現了 Encoder 和 Decoder 兩個 Trait，這樣就可以透過編解碼器來處理 ResultSet 的報文。

```
#[derive(Debug, Default)]
pub struct ResultsetCodec {
    pub next_state: DecodeResultsetState,
    pub col: u64,
    pub is_binary: bool,
    pub seq: u8,
    pub auth_info: Option<clientauth>,
}

```
![](http://img.blog.itpub.net/blog/2022/06/17/9ee0644de41b78e9.png?x-oss-process=style/bb)
圖 6

## 五、總結

以上，就是本篇文章的全部內容。在本篇文章中我們介紹了使用 Rust 實現 MySQL 代理的動機，介紹了 MySQL 協議中一些常用到的概念和 MySQL 中資料包文在網路中是如何進行交換資料的；並在最後介紹如何使用 Rust 去快速實現一個 MySQL 代理服務。更多實現細節請關注 Pisanix 程式碼倉庫。

歡迎點選連結檢視相關教學影片：https://www.bilibili.com/video/BV1B54y1o7EC?spm_id_from=333.999.0.0

## 六、相關連結

**Pisanix**
專案地址：https://github.com/database-mesh/pisanix

官網地址：https://www.pisanix.io/

Database Mesh：https://www.database-mesh.io/

**Mini-Proxy：一個最小化的 MySQL Rust 代理實現**
專案地址：https://github.com/wbtlb/mini-proxy

**社群**
目前 Pisanix 社群每兩週都會組織線上討論，詳細安排如下，歡迎各位小夥伴一起參與進來。

| 討論 | 地址 |
| ----- | ----- |
| 郵件列表 | https://groups.google.com/g/database-mesh |
| 英文社群雙週會（2022年2月27日起），週三 9:00 AM PST | https://meet.google.com/yhv-zrby-pyt |
| 中文社群雙週會（2022年4月27日起），週三 9:00 PM GMT+8| https://meeting.tencent.com/dm/6UXDMNsHBVQO |
| 微信小助手| pisanix |
| Slack| https://databasemesh.slack.com/ |
| 會議記錄| [https://bit.ly/39Fqt3x](https://bit.ly/39Fqt3x) |

**作者介紹**

王波，SphereEx MeshLab 研發工程師，目前專注於 Database Mesh，Cloud Native 研發。Linux、llvm、yacc、ebpf user， Gopher & Rustacean and c bug hunter。

GitHub：https://github.com/wbtlb</clientauth></tcpstream></option></message></:error></clientauth></box></u8></localstream>

在 Pisa-Proxy 中，如何利用 Rust 實現 MySQL 代理

相關文章