圖片
背景
最近有個項目需求：
來自同一客戶端的所有請求都被發送到同一個后端服務器，以確保會話數據或狀態在服務器之間保持一致。
會話粘性
根據上面的需求，其實就是如何實現會話粘性。
會話粘性（Session Affinity）：也稱為會話持久性（Session Persistence）或會話堅持（Session Stickiness），是一種負載均衡策略，其中來自同一客戶端的所有請求都被路由到相同的后端服務器。這樣做的目的是確保在多個服務器之間保持用戶的會話數據或狀態的一致性。通常，會話粘性通過客戶端的標識信息來實現，最常見的標識信息是客戶端的 IP 地址或Cookie。
客戶端和服務端之間的交互如下圖所示：
圖片
實現方案
Nginx 可以根據客戶端的 IP 地址，將請求路由到不同的后端服務器。如下圖所示：
圖片
三個客戶端具有不同的固定 IP，客戶端的請求達到 Nginx 之后，Nginx 對客戶端 IP 進行哈希，算出一個哈希值，映射到某個上游服務器。
服務器端會生成和存儲 session 的有效期，然后將 sessionid 返給客戶端，客戶端下次發送請求時，攜帶 sessionid。請求還是會發到上次的服務器上，服務器會校驗客戶端 sessionid 是否存在以及是否在有效期內。
ip_hash 指令
這里就需要用到 ip_hash 指令。
先來看下 ip_hash 如何用的。
Syntax: ip_hash;
Default:
Context: upstream
來看下官網的解釋：
Specifies that a group should use a load balancing method where requests are distributed between servers based on client IP addresses. The first three octets of the client IPv4 address, or the entire IPv6 address, are used as a hashing key. The method ensures that requests from the same client will always be passed to the same server except when this server is unavAIlable. In the latter case client requests will be passed to another server. Most probably, it will always be the same server as well.
我們翻譯過來的意思就是ip_hash用于指定組應使用負載平衡方法，其中請求根據客戶端 IP 地址在服務器之間分配。客戶端 IPv4 地址或整個 IPv6 地址的前三個八位字節用作散列密鑰。該方法確保來自同一客戶端的請求始終會傳遞到同一服務器，除非該服務器不可用。在后一種情況下，客戶端請求將被傳遞到另一臺服務器。最有可能的是，它也將始終是同一臺服務器。
注意 1：從版本 1.3.2 和 1.2.2 開始支持 IPv6 地址。
如果需要暫時刪除其中一臺服務器，則應使用 down 參數對其進行標記，客戶端請求才會被下一個服務器接收和處理。
注意2：在版本 1.3.1 和 1.2.2 之前， ip_hash 和權重配置不能一起使用。
使用示例
ip_hash 的配置示例如下：
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}
以下是對這個配置的詳細解釋：
- ip_hash：這是一個Nginx指令，它告訴Nginx使用客戶端的IP地址來決定將請求路由到哪個后端服務器。這意味著來自同一IP地址的所有請求都會被發送到同一個后端服務器。
- server：在 upstream backend 塊內，列出了多個后端服務器。在這個示例中，有四個服務器：backend1.example.com、backend2.example.com、backend3.example.com 和 backend4.example.com。
- backend3.example.com down：這里的 down 關鍵字表示將 backend3.example.com 標記為 "down"，即暫時禁用該服務器，不再接受新的連接。這可以用于臨時將某個服務器從負載均衡中移除，以進行維護或修復。
通過這個配置，Nginx會根據客戶端的IP地址將請求路由到相應的后端服務器，并確保來自同一客戶端的所有請求都發送到同一個后端服務器，以保持會話數據或狀態的一致性。
Github 上一個有趣的問題
我在 Github 上看到一個 ip_hash 有趣的問題：
https://gist.github.com/banjin/cf8d890591aa6c16d09e4ebfa6471284
圖片
你好。有個問題想請教一下。某個ip被hash分配到A機器后，假如機器A標記為down了，那這個ip是不是就會被分配到別的機器上了，比如機器B？如果機器A后面又好了的話，那這個ip是不是又從機器B分配回機器A了呢？相當于在A B之間來回處理了？假設客戶端 IP 為 192.168.1.10
我的測試結果如下：
- A服務 -> down 之后, 192.168.1.10 發送過來的請求會分配給 B。
- A服務-> 去掉 down之后，192.168.1.10 發送過來的請求會重新分配 A 來處理。
ip_hash 有哪些坑
1. 不適用于負載不均衡的情況：ip_hash主要用于在多個后端服務器之間實現會話粘性，但它不會考慮服務器的負載。如果服務器之間的負載不均衡，某個服務器可能會處理更多的請求，而其他服務器則可能處于空閑狀態。這可能導致資源利用不均衡。
2. 有限的負載均衡能力：ip_hash并不是一個全功能的負載均衡解決方案。它僅僅依賴于客戶端IP地址，而不考慮服務器的健康狀態或性能。如果您需要更復雜的負載均衡策略，可能需要考慮其他Nginx模塊，如least_conn或ngx_http_upstream_module，或者使用專門的負載均衡器。
3. 可能導致資源浪費：如果某個客戶端的IP地址在一段時間內請求頻率非常高，它的所有請求都將路由到同一個后端服務器。這可能導致某些服務器負載較重，而其他服務器卻處于輕負載狀態，從而導致資源浪費。
4. 不適用于動態IP分配：如果客戶端使用動態IP地址，而且IP地址可能在短時間內變化（例如，通過DHCP），那么ip_hash可能不適用，因為客戶端的IP地址可能在會話期間發生變化，導致會話狀態丟失。
5. 維護會話狀態：使用ip_hash可能需要維護會話狀態信息，這會增加一些系統復雜性。如果您需要跨多個服務器進行無狀態負載均衡，這可能不是最佳選擇。
總結
ip_hash 在解決會話粘性的場景中可以發揮出奇效，但是 ip_hash 也會存在一些問題，比如負載不均衡問題。
