> 上篇內容我們講到 OBProxy 的問題排查，將大家在使用 OBProxy 時可能遇到的問題一一分析，並給出經過實踐驗證的解決方案。從本篇開始，我將介紹 **OBProxy 在OceanBase分散式架構中的作用和原理，幫助你更透徹地瞭解OBProxy，實現“好用”和“用好”。** 同時，OBProxy 在上百家企業的持續執行，**我們積累了大量的工程實踐經驗，也將遇到的問題作為案例，伴隨 OBProxy 的原理講解分享給你，供大家參考。**

本篇從 OBProxy 的重要特性連線管理講起，其中，對連線對映關係、session狀態同步等內容，你可以將其與單機資料庫比較，體會分散式系統和單機系統的異同。

# OBProxy的連線管理步驟及原理
在正式講解之前，我先介紹一下本篇內容的技術背景。我們知道，OBProxy 為使用者提供了資料庫接入和路由功能，使用者連線 OBProxy 就可以正常使用OceanBase資料庫。使用者在使用資料庫功能時，OBProxy和OBServer進行互動，且互動流程對使用者透明，連線管理就是該互動過程中的關鍵點之一。
OBProxy的連線管理有三個特性：

1. **代理特性：**OBProxy 既是客戶端，也是服務端，還需要保證互動行為符合MySQL協議規範。
1. **功能特性：**OBProxy實現了很多的連線功能特性，如訪問不同叢集、不同租戶，再如支援主備庫、分散式下的ps功能，以及相容kill、show processlist等命令。
1. **高可用特性：**OBProxy可以處理超時、機器狀態變化、網路狀態變化等問題，遮蔽後端異常，讓使用者無感知。

接下來我們按使用 OBProxy 的操作步驟一步一步來講解連線管理內容。

## 第一步：使用者登入
### 1. 登入資訊
在登入 OBProxy 時，我們需要填寫資料庫IP和PORT、使用者名稱、密碼等資訊，對於使用者名稱，OBServer 的格式為user_name@tenant_name。因為 OBProxy 可以代理不同的叢集，所以格式又變為user_name@tenant_name#cluster_name，欄位含義如下：

- **user_name：**登入的使用者名稱，密碼儲存在OBServer中，OBProxy只做登入報文轉發不做密碼校驗。
- **tenant_name：**OBServer是多租戶架構，tenant_name表示訪問的租戶名。
- **cluster_name：**叢集名，OBProxy支援訪問多個叢集，不同叢集透過cluster_name區分。

有了這些資訊，我們就可以透過JDBC驅動、MySQL命令列、Navicat等工具連線 OBProxy 訪問資料庫了。

你可能會疑惑，使用者登入時 OBProxy 如何找到對應的機器呢？這就要依賴OCP系統（透過obproxy_config_server_url配置項指定OCP的url地址訪問），OCP會儲存叢集名和叢集的機器列表，OBProxy透過訪問OCP獲取這些資訊，整個流程如下圖。
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/53702/1661435173348-79cb6e94-bbcc-418a-8994-6b48de10d3b4.png#crop=0&crop=0&crop=1&crop=1&from=url&id=N2OtA&margin=%5Bobject%20Object%5D&originHeight=221&originWidth=721&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
有了租戶的機器列表，我們就可以進行路由轉發了。這裡需要注意的是，本系列第二篇介紹的rslist啟動方式會省略上圖中的步驟2和步驟3，這種方式只支援訪問一個叢集。

### 2. 登入認證
找到機器後，我們就可以登入認證了，關鍵資訊是使用者名稱和密碼，MySQL協議中（官方圖片中展示了Handshake相關報文，實際流程中第2步結束後服務端需要回復一個OK或者Error報文給客戶端）的互動流程如下圖。
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/53702/1660873731284-a07f4d38-4b71-4576-9247-3a4abcce8672.png#crop=0&crop=0&crop=1&crop=1&from=url&id=QJlMf&margin=%5Bobject%20Object%5D&originHeight=408&originWidth=1232&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
OBProxy 作為代理元件，要相容MySQL行為，會有更多步驟。我們以Java程式連線資料庫為例說明整個流程，在Java程式中，登入程式碼只有一行：
```
conn = (Connection) DriverManager.getConnection(URL, USER_NAME, PASSWORD);
```
但背後的原理比較複雜，如下圖所示。
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/53702/1660834139033-9ddf3165-19a8-47bd-841a-37c6e34311cc.png#crop=0&crop=0&crop=1&crop=1&from=url&id=F0NMC&margin=%5Bobject%20Object%5D&originHeight=652&originWidth=753&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
在完成協議的登入步驟（第8步）後，MySQL協議層的登入互動就結束了，但JDBC會傳送一些初始化SQL，也屬於登入過程一部分，圖中第9步表示該過程。初始化SQL有多條，內容如下：
```
set autocommit=1, sql_mode = concat(@@sql_mode,',STRICT_TRANS_TABLES')
set names utf8
SELECT @@max_allowed_packet,@@system_time_zone,@@time_zone,@@auto_increment_increment,@@tx_isolation AS tx_isolation,@@session.tx_read_only AS tx_read_only
select @@version_comment, @@version limit 1
```
上面SQL執行完成後，Java程式就可以傳送業務SQL了。

### 3. 常見登入問題
現在的你已經明白了 OBProxy 的登入原理，就可以在登入失敗時快速地定位和解決問題了。常見的問題及原因如下：

- 使用者名稱或密碼錯誤，可以透過直連OBServer確定。
- OCP故障，無法拉取叢集機器列表，可以透過curl命令訪問OCP的url確定。
- OBServer執行獲取機器列表或初始化SQL失敗，需要日誌排查定位。
- 超過最大連線數設定或不在白名單中，後文將為你詳細解讀。

對於上述問題，你可以透過本系列第三篇文章提到的檢視obproxy_error.log方式解決。

## 第二步：連線管理
登入成功後，客戶端OBProxyOBServer之間的網路連線便建立起來，此時 OBProxy 只是和其中一臺OBServer建立了連線。隨著SQL請求的到來，如果路由到新的OBServer，會和新的OBServer建立連線。在此過程中涉及連線的對映關係、狀態同步和連線功能特性，接下來一一解讀。
### 1. 連線的對映關係
連線對映主要講客戶端連線和服務端連線之間的關係，我們先從一個客戶端連線說起。當客戶端和 OBProxy 建立一個連線後，OBProxy 會和後面N個OBServer建立連線，整個關係如下圖所示。
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/53702/1661435140659-a4091063-5cb4-49f0-9f97-4d3b2480ddef.png#crop=0&crop=0&crop=1&crop=1&from=url&id=HjDoK&margin=%5Bobject%20Object%5D&originHeight=321&originWidth=531&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)

可以看到，OBProxy 按需和兩臺OBServer建立了連線。這兩個連線只屬於這一個客戶端連線，不會被其他客戶端連線複用。連線對映的關鍵點就是需要用id標識出每一個連線並記錄id之間的對映關係，我們可以將上圖抽象成模型：
AppOBProxyOBServer1
                                                                                OBServer3
這樣我們就可以用proxy_sessid唯一標識App和OBProxy之間的連線，用server_sessid唯一標識OBProxy和OBServer之間的連線。當SQL執行錯誤、執行慢等情況出現，會將對映關係列印到日誌中，這樣就將App和OBServer關聯起來，進行全鏈路問題定位。

### 2. 狀態同步
一個客戶端連線對應多個服務端連線，要保證執行結果的正確性，就要求多個服務端連線的session狀態是一致的。那麼，狀態不同步會導致什麼問題？我們舉個反例，假設使用者執行下面的SQL命令：
```
set autocommit=1;
insert into t1 values(1);
insert into t2 values(2);
```
執行過程如下：

- set autocommit=0發給OBServer1
- insert into t1 values(1)發給OBServer1
- 進行連線切換，insert into t2 values(2)發給OBServer2

![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/53702/1661741918612-2de0865a-80a5-49ca-9ccc-bdf06b4a8057.png#crop=0&crop=0&crop=1&crop=1&from=url&id=i568A&margin=%5Bobject%20Object%5D&originHeight=191&originWidth=611&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
對於第三條SQL，OBProxy 和 OBServer2 的連線並未同步連線狀態autocommit=1，這樣就可能導致第三條語句insert into t2並未提交事務。
正確的步驟是OBProxy在給OBServer2傳送INSERT SQL前，先同步autocommit變數的值。OBProxy透過版本號機制解決了狀態同步的問題，實現了database、session variables、last_insert_id、ps prepare語句的狀態同步，保證功能的正確性。

### 3. 連線功能特性
和單機資料庫不同，OBProxy改變了連線的對映關係為M:N，因此有些連線功能需要做額外處理。舉個例子，使用者透過show processlist檢視連線數，此時他希望看到的是客戶端和 OBProxy 之間的連線數，而不是 OBProxy 和OBServer之間的連線數。下面我們對常見的連線功能展開詳細介紹。
**連線粘性。**OBProxy還未實現所有功能的狀態同步，如事務狀態、臨時表狀態、cursor狀態等。對於這些功能，OBProxy只會將後續請求都發往狀態開始的節點，這樣就不需要進行狀態同步，而缺點是無法充分發揮分散式系統的優勢。因此，我們根據功能重要程度，逐步支援相關功能的分散式化。
**show processlist和kill命令配套使用。**show processlist用於展示客戶端和服務端之間的連線，對於OBProxy，show processlist只展示客戶端和OBProxy之間的連線，不展示OBProxy和OBServer之間的連線。kill命令用於殺死一個客戶端連線，客戶端連線關閉後，OBProxy也會關閉對應的服務端連線。對於OBProxy的kill命令，需要先獲取對應的id，如下圖的Id列內容（show proxysession和show processlist功能類似，show proxysession是OBProxy專屬命令）。
![](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/53702/1640920919554-5c5a9834-3d22-48a5-b208-fa6baad750be.png#crop=0&crop=0&crop=1&crop=1&from=url&id=ZCIic&margin=%5Bobject%20Object%5D&originHeight=581&originWidth=1500&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)
**負載均衡影響。**因為 OBProxy 對show processlist和kill命令做了處理，所以show processlist和kill命令只有都發往同一臺 OBProxy 才能正常工作。在公有云等環境，OBProxy前面有負載均衡，負載均衡後面掛在多個OBProxy上，此時，如果執行show prcesslist和kill命令是兩個不同的連線，負載均衡元件可能將請求發往不同的OBProxy，在這種情況下，我們最好不要使用相關命令。
介紹完OBProxy的連線對映關係、狀態同步和連線功能特性的技術原理後，你可能會覺得如果用HAProxy等普通代理，很多地方就會簡單很多，比如：

- 使用者連線普通代理後，普通代理只會和一臺OBServer建立連線，連線對映是1:1的管理。
- 普通代理的連線對映為1:1的關係，就不需要做狀態同步，連線功能也不需要特殊處理，直接轉發即可。

**那麼，為什麼還推薦使用OBProxy，它的優勢在哪裡呢？**

- 普通代理無法做高可用容災，OBProxy透過內部表、錯誤碼等資訊，會探測出OBServer狀態（升級、當機等），對OBServer節點進行拉黑和洗白。
- 普通代理無法充分發揮OceanBase資料庫的效能，連線建立後，普通代理無法將SQL發往其他OBServer節點，有時執行鏈路會更長。OBProxy可以精準路由，並實現讀寫分離等特性。
- 普通代理功能有限，無法適配OceanBase主備庫、複製表、LDC架構等特性。

以上就是使用OBProxy 的步驟及其原理，如果想了解更深層次的連線原理知識，我們需要追溯到TCP協議。因為OBProxy的連線基於TCP協議，瞭解TCP協議的連線機制就能更透徹的掌握連線管理的功能及連線問題定位等知識。

# 延伸知識點1：基於TCP協議的連線機制
## TCP引數
OBProxy在程式碼層面設定了TCP的no_delay和keepalive屬性，以保證低延遲、高可用等特性。

- **no_delay屬性**透過禁用TCP Nagle演算法解決延遲問題。在Linux的網路棧中預設啟用Nagle演算法，用於解決網路報文小分組出現，但會導致網路報文傳送延遲。我們曾在生產環境中遇到TCP未禁用Nagle演算法的情況，導致一條SQL傳送耗時40ms左右，這是不滿足業務要求的。
- **keepalive屬性**用於故障探測。及時發現機器故障，將無效的連線關閉，是TCP層高可用一部分。

這兩個屬性可以透過OBProxy的配置項進行配置，推薦配置如下：
```
## 和OBServer的tcp連線設定
sock_option_flag_out = 3;  --  這是個二進位制位引數，bit 0 表示否是啟用 no_delay，bit 1 表示是否啟用 keepalive。3的二進位制是 11，表示啟用 no_delay 和 keepalive
server_tcp_keepidle = 5;  --  啟動keepalive探活前的idle時間，5秒。
server_tcp_keepintvl = 5;  -- 兩個keepalive探活包之間的時間間隔，5秒
server_tcp_keepcnt = 2;  --  最多傳送多少個keepalive包，2個。最長5+5*2=15秒發現dead_socket。

## 和客戶端的tcp連線設定
client_sock_option_flag_out = 3;  --  同上
client_tcp_keepidle = 5;  --  同上
client_tcp_keepintvl = 5;  -- 同上
client_tcp_keepcnt = 2;  --  同上
```
我們在生產環境中已經驗證了no_delay和keepalive屬性，你可以放心使用。對於其他TCP引數，我們直接使用預設值，還沒有調參的需求。

## 超時引數
我們在排查問題時，偶爾會遇到TCP連線斷了的情況，但無法確定是客戶端斷連還是服務端斷連。根據經驗判斷，往往是超時機制觸發的。這裡針對幾種超時機制介紹一下全鏈路解決方案。
### 1.JDBC超時
#### （1）socketTimeout
socketTimeout是Java socket的超時時間，指的是業務程式和後端資料庫之間TCP通訊的超時時間，如果業務程式傳送一個MySQL Packet後，超過socketTimeout的時間還沒有從後端資料庫收到Response報文，這時候JDBC會丟擲異常，程式執行失敗。
socketTimeout單位是毫秒，可以透過以下方式設定：
```
jdbc:mysql://$ip:$port/$database?socketTimeout=60000
```
#### （2） connectTimeout
connectTimeout是業務程式使用jdbc跟後端資料庫建立TCP連線的超時時間，也相當於是在connect階段的socketTimeout，如果TCP連線超過這個時間沒有建成功，jdbc會丟擲異常。
connectTimeout的單位是毫秒，可以透過以下方式設定：
```
jdbc:mysql://$ip:$port/$database?socketTimeout=60000&connecTimeout=5000
```
#### （3）queryTimeout
queryTimeout是業務程式執行SQL時，jdbc設定的本地的超時時間。在業務呼叫jdbc的介面執行SQL時，jdbc內部會開啟這個超時機制，超過quertTimeout沒有執行結束，jdbc會在當前連線上傳送一個kill query給後端資料庫，並給上層業務拋一個MySQLTimeoutException。
queryTimeout單位是秒，可以透過以下方式進行設定：
```
1、透過jdbc的Statement.setQueryTimeout介面來設定
    int queryTimeout = 10;
java.sql.Statement stmt = connection.CreateStatement();
stmt.setQueryTimeout(queryTimeout);
```

這裡需要特別說明的是，如果要使用queryTimeout，建議設定一個比socketTimeout小的值，否則會先觸發網路超時從而導致斷連線。但我們並不推薦使用queryTimeout，你可以使用OceanBase資料庫的ob_query_timeout屬性。
#### （4）JDBC超時實踐
JDBC 重要的幾個超時引數，均可以設定到連線池的 ConnectionProperties 中，或者 JDBC URL 上：

| 引數 | 說明 | 推薦值 |
| --- | --- | --- |
| socketTimeout | 網路讀超時時間，如果不設定預設是 0，使用 OS 預設超時時間 | 5000ms |
| connectTimeout | 連結建立超時時間，如果不設定預設是 0，使用 OS 預設超時時間 | 500ms |

這些引數是我們根據螞蟻內部OLTP業務總結而來，供你參考。

### 2.OceanBase資料庫超時
OceanBase資料庫有自己特定的超時引數，這些引數和JDBC的不同在於**OceanBase觸發超時後的行為是返回ERROR報文而不是斷連線**。
#### （1） ob_query_timeout
ob_query_timeout是OBServer SQL級別的超時引數，可以透過hint或者session變數設定，表示執行一個SQL超時時間。當業務的SQL在資料庫執行時間超過ob_query_timeout設定的值後，OBServer會返回一個ERROR包給客戶端，錯誤碼是4012。 ob_query_timeout的預設值是10000000(10s), 單位是微秒。可以透過以下幾種方式設定：
```
// Java程式示例

// 1、透過sql設定session變數或者global變數，設定完成之後，當前連線生效
stmt.execute("set @@ob_query_timeout = 10000000");
stmt.execute("set @@global.ob_query_timeout = 10000000");

// 2、透過在業務sql中新增hint設定，當前sql生效
String sql = "/*+ QUERY_TIMEOUT(10000000)*/ select count(*) from XXX";
stmt.execute(sql);
```
#### （2）ob_trx_timeout
ob_trx_timeout是OBServer的事務超時時間，是一個session變數，當一個事務執行超過ob_trx_timeout還沒有結束時，OBServer同樣會返回4012的ERROR報文給客戶端。如果超時發生時，事務還沒有提交，那麼OBServer會回滾這個事務；如果發生在commit階段，由於事務狀態未定，OBServer不會主動回滾它。ob_trx_timeout預設值是100000000（100s），單位是微秒，可以透過以下方式設定：
```
// Java程式示例

// 透過sql設定session變數或者global變數，設定完成之後，當前連線生效
stmt.execute("set @@ob_trx_timeout = 100000000");
stmt.execute("set @@global.ob_trx_timeout = 100000000");
```

#### （3）相容MySQL超時
除了上述OceanBase資料庫特有的超時引數，OceanBase資料庫還相容了MySQL的超時引數，可以參考MySQL [超時文件](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html)，MySQL的超時引數會導致斷連線，有三個引數。

- **wait_timeout：**空閒session時間，預設為8個小時，超過該時間未傳送任何SQL就會斷連。
- **net_read_timeout：**等待從連線上讀取資料的超時時間。超時會導致連線關閉。
- **net_write_timeout：**等待從連線上寫入資料的超時時間。超時會導致連線關閉。

因為大部分超時機制觸發後會直接關閉連線，並且不列印超時日誌，所以不瞭解超時機制的話很難確定TCP斷連的原因，但瞭解後透過觀察執行時間或調整引數基本就能確定問題。OBProxy 作為代理層，並沒有增加超時機制，不會讓機制更加複雜，同時，OBProxy 會感知資料庫超時引數的設定，讓整體表現符合超時機制。

# 延伸知識點2：常用網路工具
在很多時候我們需要了解系統網路行為，從而更好地解決問題。比如，在OBProxy 日誌中出現了Connect Error，我們就可以透過ping命令進一步證實兩臺機器之間網路不通。接下來為你介紹一些常用的網路工具。
## ping和telnet命令
ping和telnet命令簡單好用，ping命令可以確定兩臺機器之間的網路是否連通，並且可以瞭解網路之間的延遲，這對解決很多問題都非常有用。比如，延遲幾十毫秒，判定為路由到了其他城市的機房，這在oltp業務中是不符合預期的。telnet命令可以進一步確定機器埠是否在監聽，從而發現服務程式未啟動、程式core掉等問題。
## 抓包工具
當問題涉及多個模組的協議互動時，只分析日誌無法獲得更多有用資訊，此時可以使用tcpdump工具獲取網路真實情況。舉個例子，如果在OBProxy日誌看到資料庫執行SQL慢，而在OBServer看到SQL執行很快，此時就會懷疑網路問題，只有根據TCP報文才能確定是否是網路問題。
標準部署中，OBProxy的埠是2881，OBServer的埠是2883，如果抓OBProxy和OBServer的互動報文，可以在OBProxy的機器執行：
```
sudo tcpdump -i any port 2881 -w xxx.cap
```
TCP報文就會儲存在xxx.cap中。得到該檔案複製到本地機器使用wireshark軟體分析即可。
除了上面介紹的命令，還有ifconfig、ss、lsof、curl等命令都非常有用，網路上資料很多，此處就不作更多介紹了。
總之，在分散式系統中，網路問題很常見。瞭解背後的原因，需要對作業系統、資料庫系統、網路工具都非常熟悉，因此增加了判斷難度。上述內容對這些知識點都做了詳細介紹，幫助你更好地瞭解分散式資料庫系統。

# 延伸知識點3：連線管理的常見問題
雖然連線管理的知識點很多，但當出現連線問題後，客戶端報錯基本都是Communications link failure。這裡關鍵點就是透過“關鍵資訊”將TCP的兩端聯絡起來，獲得更多有用資訊去進一步分析。如“關鍵資訊”是SQL和時間點，那麼就可以去obproxy_error.log中去檢視，找到日誌記錄後，可以根據本系列第三篇文章介紹的內容去進一步排查。
這裡我們舉兩個例子說明。例子1客戶端報錯：
```
--- Cause: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 70,810 milliseconds ago. The last packet sent successfully to the server was 5,005 milliseconds ago.
```
分析報錯資訊，可以看到客戶端上次從服務端收到請求是70810ms之前，客戶端上次往服務端傳送資料是5005ms（5s）之前。這是在執行SQL過程中出現了問題，一般是Java本身設定了sockettimeout=5s導致的，這可以嚮應用開發者確認。
例子2客戶端報錯：
```
--- Cause: com.alipay.oceanbase.obproxy.druid.pool.GetConnectionTimeoutException: get connection timeout, maxWait=500ms, maxCount=10, currentCount=11,
```
可以看到這是個Druid連線池的報錯，獲取連線超時。此時SQL還沒有執行，但從連線池已經拿不到連線了，問題原因就比較複雜。一般原因有：

- 連線池本身配置連線數太少不夠用，參考maxCount的值，一般調大可以解決。
- 有慢SQL導致連線沒有及時歸還，這種問題就需要排查哪些SQL執行慢。

可見報錯只是一種表象，很難一下就確定根本原因，需要收集更多資訊去深入排查。

# 總結
連線管理涉及的綜合知識點多，涉及的模組（包括驅動、OBProxy和OBServer）也多，因此變得複雜，但這也是微服務、分散式資料庫的共同“痛點”。本文我們從使用者登入講起，分別介紹了連線管理、網路技術和常見問題，將相關原理和實踐介紹給你。OBProxy經歷多年實踐，解決了很多連線管理的問題，n也歡迎大家學習交流。

# 課後互動
### 上期互動答案
**小明想檢視所有經過 OBProxy 的 SQL，請問有什麼辦法？**
答：obproxy_digest.log是審計日誌，記錄了所有執行時間大於query_digest_time_threshold的SQL，因此可以修改query_digest_time_threshold的值為1us，就可以在obproxy_digest.log中看到所有經過OBProxy的日誌了。

### 本期互動問題
JDBC和OBProxy建立了一個連線，晚上OBProxy被kill掉重啟，請問此時JDBC會丟擲異常嗎？
歡迎你在問答區發帖討論，下篇文章揭曉答案。

高效能資料訪問中介軟體 OBProxy（四）：一文講透連線管理

相關文章