在上一篇文章《[MQTT Broker 叢集詳解（一）：負載均衡](http://blog.itpub.net/69958136/viewspace-2787449/)》中，我們簡單介紹了 MQTT 負載均衡：負載均衡既可以應用於傳輸層，也可以用於應用層。在本文中，我們將詳細介紹應用層負載均衡，其中最有趣的部分：粘性會話（sticky-session）。

本文由兩部分組成，第一部分將介紹 MQTT 會話，以及在分散式 [MQTT Broker](https://www.emqx.io/zh) 叢集中處理會話面臨的挑戰；第二部分是透過在 [EMQ X 4.3](https://www.emqx.com/zh/products/emqx) 叢集前面配置 [HAProxy 2.4](https://www.haproxy.org/) 負載均衡器，帶讀者親自體驗如何充分利用粘性會話實現負載均衡。

## MQTT 會話

為了持續接收訊息，[MQTT 客戶端](https://www.emqx.com/zh/blog/introduction-to-the-commonly-used-mqtt-client-library)通常會連線至 MQTT Broker 進行訂閱並保持長期連線。由於網路問題或客戶端軟體維護等原因，連線可能會中斷一段時間，這並不罕見，但客戶端通常希望在重新連線成功後仍然能接收到中斷期間漏收的訊息。

因此，為客戶端提供服務的 MQTT Broker 應該為客戶端保持會話（根據客戶端的請求，將「Clean-Session」標誌設定為  false）。此時，即使客戶端斷開連線，訂閱者當前訂閱的主題以及傳遞給這些主題的訊息（QoS1 和 2）等也會由訊息伺服器（broker）保留。

當具有持久會話的客戶端重新連線時，它不需要重新訂閱主題，訊息伺服器應該將所有未傳送的訊息傳送給該客戶端。

我們之前寫過一篇關於 [MQTT 會話](https://www.emqx.com/zh/blog/mqtt-session)的文章，如果您對 MQTT 會話的技術細節感興趣，可以透過閱讀這篇文章做進一步瞭解。

### 會話接管

當 MQTT Brokers 形成叢集時，事情會變得更加複雜。從客戶端的角度來看，要連線的伺服器不止一個，很難知道哪個伺服器最適合連線。我們需要網路中的另一個關鍵元件：負載均衡器。負載均衡器成為整個叢集的接入點，並將客戶端的連線路由到叢集中的某一個伺服器。

如果客戶端透過負載均衡器連線到伺服器（例如，node1），然後斷開連線並稍後重新連線，則新連線可能會路由到叢集中的不同伺服器（例如，node3）。在這種情況下，node3 應該在客戶端斷開連線時開始向客戶端傳送未傳送的訊息。

實現叢集範圍的持久會話有很多不同的策略。例如，整個叢集可以共享一個全域性儲存來儲存客戶端的會話。

然而，更具可擴充套件性的解決方案通常以分散式方式解決這個問題，即資料從一個節點遷移到另一個節點。這種遷移稱為會話接管。會話接管應該對客戶端完全透明，但它是有代價的，尤其是當有很多訊息需要處理時。

![會話接管](https://static.emqx.net/images/ea4c881df579ece79600af69bec76244.png)

### 粘性會話解決方案

這裡的「粘性」一詞指的是負載均衡器能夠在重新連線時將客戶端路由到之前伺服器的能力，這可以避免會話接管。當有許多客戶端在同一時間重新連線時，或者在一個有問題的客戶端反覆斷開連線並再次連線的情況下，這是一個特別有用的功能。

為了讓負載均衡器以「粘性」方式分派連線，伺服器需要知道連線請求中的客戶端識別符號（有時是使用者名稱）——這需要負載均衡器檢查 MQTT 資料包以查詢此類資訊。

一旦獲得客戶端識別符號（或使用者名稱），對於靜態叢集，伺服器可以將客戶端識別符號（或使用者名稱）雜湊到伺服器 ID。或者為了更好的靈活性，負載均衡器可以選擇維護一個從客戶端識別符號（或使用者名稱）到目標節點 ID 的對映表。

在下一節中，我們將演示 HAProxy 2.4 中的粘性表策略。

## 使用 HAProxy 2.4 實現粘性會話

為了儘量減少先決條件，在這個演示叢集中，我們將在 docker 容器中啟動兩個 EMQ X 節點和一個 HAProxy 2.4。

### 建立 docker 網路

為了使容器彼此連線，我們為它們建立了一個 docker 網路。

```
docker network create test.net
```

### 啟動兩個 EMQ X 4.3 節點

為了使節點彼此連線，應該在網路名稱空間（`test.net`）中分配容器名稱和 EMQX 節點名稱。

#### 啟動 node1

```
docker run -d \
  --name n1.test.net \
  --net test.net \
  -e EMQX_NODE_NAME=emqx@n1.test.net \
  -e EMQX_LISTENER__TCP__EXTERNAL__PROXY_PROTOCOL=on \
  emqx/emqx:4.3.7
```

#### 啟動 node2

```
docker run -d \
  --name n2.test.net \
  --net test.net \
  -e EMQX_NODE_NAME=emqx@n2.test.net \
  -e EMQX_LISTENER__TCP__EXTERNAL__PROXY_PROTOCOL=on \
  emqx/emqx:4.3.7
```

> **注意環境變數**
>
> `EMQX_LISTENER__TCP__EXTERNAL__PROXY_PROTOCOL`. 該變數是為TCP監聽器啟用二進位制代理協議，以便伺服器可以獲得客戶端的真實 IP 地址資訊，而不是負載均衡器的 IP 地址。

### 使 EMQ X 節點加入叢集

```
docker exec -it n2.test.net emqx_ctl cluster join emqx@n1.test.net
```

如果一切按預期進行，應該列印輸出這樣的日誌：

```
[EMQ X] emqx shutdown for join
Join the cluster successfully.
Cluster status: #{running_nodes => ['emqx@n1.test.net','emqx@n2.test.net'], stopped_nodes => []} 
```

###  啟動 HAProxy 2.4

建立檔案 `/tmp/haproxy.config`，內容如下：

```
global
  log stdout format raw daemon debug
  nbproc 1
  nbthread 2
  cpu-map auto:1/1-2 0-1
  # Enable the HAProxy Runtime API
  # e.g. echo "show table emqx_tcp_back" | sudo socat stdio tcp4-connect:172.100.239.4:9999
  stats socket :9999 level admin expose-fd listeners

defaults
  log global
  mode tcp
  option tcplog
  maxconn 1024000
  timeout connect 30000
  timeout client 600s
  timeout server 600s

frontend emqx_tcp
  mode tcp
  option tcplog
  bind *:1883
  default_backend emqx_tcp_back

backend emqx_tcp_back
  mode tcp

# Create a stick table for session persistence
  stick-table type string len 32 size 100k expire 30m

# Use ClientID / client_identifier as persistence key
  stick on req.payload(0,0),mqtt_field_value(connect,client_identifier)

# send proxy-protocol v2 headers
  server emqx1 n1.test.net:1883 check-send-proxy send-proxy-v2
  server emqx2 n2.test.net:1883 check-send-proxy send-proxy-v2
```

在測試 docker 網路中啟動 haproxy：

```
docker run -d \
  --net test.net \
  --name proxy.test.net \
  -p 9999:9999 \
  -v /tmp/haproxy.cfg:/haproxy.cfg \
  haproxy:2.4 haproxy -f /haproxy.cfg
```

### 測試

現在我們使用流行的 mosquitto MQTT 客戶端（也在 docker 中）對其進行測試。

我們啟動一個訂閱者（名為 `subscriber1`）訂閱 `t/#` 主題

```
docker run --rm -it --net test.net eclipse-mosquitto \
	mosquitto_sub -h proxy.test.net -t 't/#' -I subscriber1
```

然後從另一個客戶端向 `t/xyz` 釋出一條 `hello` 訊息

```
docker run --rm -it --net test.net eclipse-mosquitto \
	mosquitto_pub -h proxy.test.net -t 't/xyz' -m 'hello'
```

如果一切都按預期進行，訂閱者應該列印出 `hello` 訊息。

## 檢查 HAProxy 中的粘性表

我們還可以使用如下命令檢查在 HAProxy 中建立的粘性表。這需要 `socat` 命令，所以我們從 docker 主機執行它。

```
show table emqx_tcp_back" | sudo socat stdio tcp4-connect:127.0.0.1:9999
```

該命令應該列印當前連線，如下所示：

```
# table: emqx_external_tcp_listners, type: string, size:102400, used:1
0x7f930c033d90: key=subscriber1 use=0 exp=1793903 server_id=2 server_key=emqx2
```

在這個例子中，客戶端 `subscriber1` 被固定連線到伺服器 `emqx2`。

## 結語

至此，我們可以瞭解到從客戶端的角度看，EMQ X 叢集是如何透過負載均衡器對外部提供服務的。

在本系列文章的後續內容中，我們將跟蹤一個 MQTT 訊息從釋出者到訂閱者的全過程，以便大家瞭解 EMQ X 如何將它在叢集中複製和轉發。敬請期待。

## 本系列中的其它文章

- [MQTT Broker 叢集詳解（一）：負載均衡](http://blog.itpub.net/69958136/viewspace-2787449/)

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/mqtt-broker-clustering-part-2-sticky-session-load-balancing](https://www.emqx.com/zh/blog/mqtt-broker-clustering-part-2-sticky-session-load-balancing)
>
>技術支援：如對本文或 EMQ 相關產品有疑問，可訪問 EMQ 問答社群 [https://askemq.com](https://askemq.com) 提問，我們將會及時回覆支援。
>
>更多技術乾貨，歡迎關注我們公眾號【EMQ 中文社群】。

粘性會話負載均衡 - MQTT Broker 叢集詳解（二）

相關文章