全部產品
Search
文件中心

Tair (Redis® OSS-Compatible):叢集代理模式串連池功能最佳實務

更新時間:Nov 20, 2025

叢集代理模式的串連池功能,通過池化和複用代理(Proxy)到資料庫(DB)的串連,解決因特定狀態化命令導致的後端 DB 串連數耗盡問題,以保障Tair (Redis OSS-compatible)執行個體的穩定性。

業務情境說明

雲原生叢集執行個體代理模式,常規命令通過共用串連轉寄,用戶端串連數的增加不影響後端 DB 的串連數。當商務邏輯包含特定狀態化命令時,Proxy 與資料節點之間的串連會從“共用模式”轉為“獨享模式”。

在獨享模式下,每個用戶端串連將在資料節點上建立一個對應的獨享串連。這會導致在高並發情境下,資料節點的串連數隨用戶端串連數線性增長,進而觸發 max number of clients reached 錯誤,導致服務中斷。

在使用 watch 或阻塞類請求時,通過擴容增加分區數並不能解決單個分區上串連數過高的問題。

觸發“獨享模式”的命令主要包括:

  • 事務命令: MULTI/EXEC (在 WATCH 之後)

  • 阻塞命令: BLPOP, BRPOP, BRPOPLPUSH, XREAD ... BLOCK ...

串連池功能通過池化和複用 Proxy 到資料節點的獨享串連,降低資料節點上的串連數,從而避免因串連數超限導致的請求失敗。

方案架構

串連池功能在每個 Proxy 子執行個體上獨立運行,為該 Proxy 到每個資料節點的串連維護一個專用的串連池。

樣本說明:

在未使用串連池時,用戶端與Proxy之間的每個串連都會在後端訪問的每個資料分區上建立一個獨立串連。例如,10個用戶端串連都訪問5個分區時,將導致總共 10 × 5 = 50 個串連。

而當開啟串連池後,代理會為每個資料分區維護一個有限的串連池,用戶端請求會複用這些池中的串連。這顯著減少了實際建立的資料庫連接數。例如,相同的10個用戶端串連,可能只需每個分區維護2個串連池中的串連,總計僅需 2 × 5 = 10 個串連。

工作流程:

  1. 當用戶端串連(Client Conn)發起獨享模式請求時,Proxy 節點將從對應的資料分區串連池中擷取一個空閑串連。

  2. 池命中:如果池中有空閑串連,Proxy 立即將該串連綁定到用戶端串連,用於轉寄請求。請求完成後,串連被解除綁定並返回串連池,以供其他用戶端複用。

  3. 池未命中:如果池中無空閑串連,Proxy 將在池中建立一個新串連。請求完成後

    1. 如果池內總串連數未達到上限(private_conn_pool_max_idle_per_db),此串連進入池內。

    2. 如果池內總串連數已達到上限,此串連會立刻釋放(短串連模式)。

這種最佳化極大地減輕了資料庫的串連管理負擔,減少了資源開銷,提高了資料庫的穩定性和輸送量。

適用範圍

執行個體需滿足以下條件:

啟用串連池功能

通過修改執行個體參數開啟串連池功能。此操作支援熱更新,無需重啟執行個體,對業務無影響。

  1. 訪問執行個體列表,在上方選擇地區,然後單擊目標執行個體ID。

  2. 在左側導覽列中,單擊參數設定

  3. 在參數列表中找到 private_conn_pool_enabled,單擊其右側的修改

  4. 在彈出的對話方塊中,將參數值修改為 1,然後單擊確定

後續可通過CloudMonitor控制台找到對應執行個體,查看基礎監控項Proxy到DB串連數,對比開啟前後資料變化。

配置詳解與調優指南

配置名

含義

預設值

取值範圍

private_conn_pool_enabled

串連池功能開關。1 為開啟,0 為關閉。

0

[0|1]

private_conn_idle_time_sec

池中空閑串連的存活時間(秒)。超過此時間未被使用的空閑串連將被關閉。值為 0 表示立即關閉。

60

[0-4294967295]

private_conn_pool_max_idle_per_db

每個 Proxy 節點為每個資料節點維護的最大空閑串連數。當一個串連使用完畢後,如果池中空閑串連數已達到此上限,該串連將被關閉而不是返回串連池。

1000

[0-4294967295]

private_conn_pool_min_idle_per_db

每個 Proxy 節點為每個資料節點維護的最小空閑串連數。池中空閑串連數低於此值時,即使達到 private_conn_idle_time_sec 也不會被回收。

0

[0-4294967295]

情境化調優建議

  • 通用情境:建議保持預設配置,適用於大多數業務。

  • 高並發短事務情境(例如:秒殺業務)

    • 特徵:串連佔用時間短,借還操作頻繁。

    • 建議private_conn_pool_max_idle_per_db 建議設定為能夠覆蓋業務高峰期並發請求數的值,以最大化串連複用率,避免降級為短串連。private_conn_idle_time_sec 建議使用預設值或適當縮短,以在流量低穀時更快釋放資源。

  • 長阻塞業務情境(例如:隊列消費者使用 )

    • 特徵:串連長時間被佔用,不歸還到池中。

    • 建議:建議調高 private_conn_pool_max_idle_per_db 以容納並發的消費者數量。建議將 private_conn_pool_min_idle_per_db 設定為略高於平均並發數的值,以“預熱”串連,減少新消費者啟動時的建連延遲。

  • 執行個體規格較低或記憶體敏感情境

    • 特徵:需要嚴格控制記憶體佔用。

    • 建議:建議調低 private_conn_pool_max_idle_per_dbprivate_conn_pool_min_idle_per_db。此操作會犧牲少量效能(可能增加短串連建立的幾率),以節省資料節點的記憶體資源。

注意事項

  • 設定合理的private_conn_pool_min_idle_per_db

    每個空閑串連會在後端 DB 節點上消耗一定的記憶體資源。在多分區、多 Proxy 節點的執行個體中,過高的 private_conn_pool_min_idle_per_db 設定可能導致較高的記憶體佔用。

  • 避免不必要的 DB 環境切換

    當串連池中的串連被複用於訪問不同 DB 索引的用戶端時,Proxy 需要執行 SELECT 命令來切換上下文,此操作會增加 DB 的負載和請求延遲。建議在應用設計上,確保所有用戶端使用相同的 DB 索引(通常是 DB 0)。

  • 不適用於發布訂閱命令

    串連池功能不適用於 SUBSCRIBE/PSUBSCRIBE 等發布訂閱命令。這些命令會永久佔用串連,因此串連不會被池化管理。

相關文檔