← 返回

如何在 OpenResty Edge 中啟用粘性 Cookie（會話保持）

章亦春釋出於 May 25, 2023 更新於 Aug 10, 2026

預計閱讀 6 分鐘

閱讀次數

OpenResty Edge 中的 Sticky Cookie 會把每個客戶端固定到同一臺後端上游伺服器，讓一個會話中的所有請求都落到同一臺主機上。OpenResty Edge 會下發一個粘性 Cookie，使得同一客戶端的後續請求都返回到同一臺伺服器——從而實現會話親和（會話保持），且無需改動任何 Nginx 配置，也無需過載閘道器。你只需在頁面規則裡開啟一個開關即可啟用，粒度可以是上游叢集級別，也可以是單臺伺服器級別。本教程將演示如何啟用 Sticky Cookie、驗證請求確實固定在同一臺後端，然後再禁用它、觀察流量恢復輪詢分發。

首先在啟用 Sticky Cookie 的情況下傳送兩個請求，我們會看到它們被髮送到了同一個後端伺服器。

之後在禁用 Sticky Cookie 的情況下再傳送兩個請求，然後會觀察到這次的兩個請求被髮送到了兩個不同的後臺伺服器。

為上游啟用 Sticky Cookie（伺服器級別親和）

讓我們進入 OpenResty Edge 的 Admin Web 控制檯。這是我們控制檯的樣本部署。每個使用者都有自己的本地部署。

我們可以繼續使用之前的示例應用，test-edge.com。

進入該應用程式。

轉到 “Upstreams” 頁面。

我們已經定義了一個上游。

這個上游目前有一個上游伺服器。

我們需要兩個上游伺服器。現在再增加一個伺服器。

點選 “Add a new upstream server” 按鈕。

輸入上游伺服器的主機名。

檢查一下上游伺服器是否可用。

可以看到返回了開源 OpenResty 的預設主頁，與預期結果相符。

儲存上游。

轉到 “Page Rules” 頁面。

在之前的教程中我們已經設定了一個反向代理的頁面規則。

編輯這個頁面規則，啟用 Sticky Cookie。

開啟 Sticky Cookie 的開關。

由於我們的上游伺服器是在一個上游叢集裡面，這裡我們選擇使用伺服器級別的 Sticky Cookie。

選擇伺服器級別。

這裡我們可以設定 Sticky Cookie 的過期時間。

使用預設值 0，代表永遠不會過期。

儲存這個頁面規則。

接下來，我們將會建立一個動態指標來檢視請求的分佈。注意對於 Sticky Cookie 的設定來說這一步並不是必須的。Sticky Cookie 功能不依賴任何動態指標。

單擊 “New Metric” 按鈕。

我們把這個動態指標命名為 “Upstream Server Request Count”。

新增一個描述。

設定上報間隔為 10 秒。

輸入 Metric SQL 語句。它將選擇上游伺服器地址。

從所有的請求中。

並且按照上游伺服器地址分組顯示。

儲存這個指標。

像往常一樣，需要釋出一個新的版本來推送我們剛才的改動。

點選這個按鈕。

釋出！

新版本現在已經同步到所有的閘道器伺服器上了。

剛才的改動已經被推送到所有的閘道器叢集和伺服器。

這些配置的變化不需要伺服器過載、重啟或二進位制升級。所以它是非常高效和可擴充套件的。

透過 OpenResty Edge 管理所有應用程式

測試 Sticky Cookie：所有請求命中同一臺後端

現在讓我們來傳送兩個請求。傳送第一個請求。

傳送第二個請求。

所有請求傳送成功。

來看一下動態指標所記錄的資料。

選擇柱狀圖。

可以看到所有請求都被髮送到同一個上游伺服器上。

正如下方圖片所顯示的那樣。

接下來，我們將演示禁用 Sticky Cookie 的情況。

先清理一下指標資料。

這裡需要點選確認。

清理工作已經完成，現在來禁用 Sticky Cookie。

再次編輯這個頁面規則。

關閉 “Sticky Cookie” 開關。

注意，均衡策略是 “Round Robin”。

儲存頁面規則。

像往常一樣，需要釋出一個新的版本來推送我們剛才的改動。

點選這個按鈕。

釋出！

新版本現在已經同步到所有的閘道器伺服器上了。

再次測試：請求分散到多臺後端

接下來，再次傳送兩個請求。

傳送第一個請求。

傳送第二個請求。

所有請求傳送完成。

重新檢查動態指標。

點選柱狀圖。

可以看到這兩個請求分別訪問了不同的上游伺服器。

正如下方圖片顯示的那樣。

透過 Sticky Cookie，OpenResty Edge 讓客戶端與某個上游叢集或單臺上遊伺服器保持親和——實現會話保持，且無需任何 Nginx 配置或過載。Sticky Cookie 只在單個上游內固定流量；若要在多個地區或資料中心之間排程使用者流量，請參閱全域性伺服器負載均衡的工作原理；對於非 HTTP 服務，請參閱 OpenResty Edge 中的 TCP 負載均衡。

常見問題

粘性會話（sticky session）和會話親和（session affinity）有甚麼區別？

它們描述的是同一種行為：在一個會話期間把客戶端固定到同一臺後端。“會話親和”（也稱會話保持）是目標，而粘性 Cookie 是實現這一目標的機制。在本演示中，OpenResty Edge 會下發一個粘性 Cookie，使同一客戶端的每個請求都回到同一臺上遊伺服器。

當來自同一客戶端的請求需要持續命中同一臺後端伺服器時，就應該使用 Sticky Cookie。本演示直觀地展示了效果：啟用 Sticky Cookie 時，兩個請求落在同一臺上遊伺服器上；禁用後，同樣的兩個請求會被輪詢分發到不同的伺服器。

伺服器級別的 Sticky Cookie 將客戶端固定到單臺上遊伺服器，而叢集級別的 Sticky Cookie 將客戶端固定到一個上游叢集。本教程中的上游伺服器都位於同一個上游叢集內，因此我們選擇伺服器級別，讓每個客戶端保持在同一臺伺服器上。

過期時間控制粘性 Cookie 的有效時長。預設值 0 表示 Cookie 永不過期，因此客戶端會一直固定在同一臺後端伺服器上。如果希望親和關係在一段時間後重置，請設定一個非零值。

關於 OpenResty Edge

OpenResty Edge 是一款專為微服務和分散式流量架構設計的全能型閘道器軟體，由我們自主研發。它集流量管理、私有 CDN 構建、API 閘道器、安全防護等功能於一體，幫助您輕鬆構建、管理和保護現代應用程式。OpenResty Edge 擁有業界領先的效能和可擴充套件性，能夠滿足高併發、高負載場景下的苛刻需求。它支援排程 K8s 等容器應用流量，並可管理海量域名，輕鬆滿足大型網站和複雜應用的需求。

申請試用 OpenResty Edge

如果你喜歡這個教程，請訂閱這個部落格網站和我們的 YouTube 頻道或 B 站頻道。謝謝！

關於作者

章亦春是開源 OpenResty^® 專案創始人兼 OpenResty Inc. 公司 CEO 和創始人。

章亦春（Github ID: agentzh），生於中國江蘇，現定居美國灣區。他是中國早期開源技術和文化的倡導者和領軍人物，曾供職於多家國際知名的高科技企業，如 Cloudflare、雅虎、阿里巴巴, 是 “邊緣計算“、”動態追蹤 “和 “機器程式設計 “的先驅，擁有超過 22 年的程式設計及 16 年的開源經驗。作為擁有超過 4000 萬全球域名使用者的開源專案的領導者。他基於其 OpenResty^® 開源專案打造的高科技企業 OpenResty Inc. 位於美國矽谷中心。其主打的兩個產品 OpenResty XRay（利用動態追蹤技術的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最適合微服務和分散式流量的全能型閘道器軟體），廣受全球眾多上市及大型企業青睞。在 OpenResty 以外，章亦春為多個開源專案貢獻了累計超過百萬行程式碼，其中包括，Linux 核心、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，並編寫過 60 多個開源軟體庫。