在Tair(Redis OSS-compatible)叢集架構和讀寫分離架構中,Proxy 伺服器(Proxy)承擔著路由轉寄、負載平衡和容錯移轉等職責,可以協助您簡化用戶端的邏輯,同時支援多資料庫(DB)、緩衝熱點資料等進階功能。通過瞭解Proxy的路由轉寄規則和特定命令的處理方式,有助於您設計更高效的業務系統。
Proxy介紹
Proxy 伺服器(Proxy)是Tair執行個體中的一個組件(單節點架構),不會佔用資料分區的資源,通過多個Proxy節點實現負載平衡及容錯移轉。
Proxy能力 | 說明 |
叢集版使用模式轉換 | Proxy能夠實現架構轉換,協助您如同在使用標準架構一樣地使用叢集架構。Proxy支援對DEL、EXISTS、MGET、MSET、SDIFF與UNLINK等命令進行跨Slot的多Key操作,更多資訊請參見代理模式(Proxy)支援的命令列表。 當標準架構無法支撐業務發展時,您無需修改代碼即可將標準架構的資料移轉至帶有Proxy的叢集架構,大幅度降低業務改造成本。 |
負載平衡和路由轉寄 | Proxy與後端的資料分區建立長串連,負責請求負載平衡和路由轉寄操作,關於轉寄規則的介紹,請參見Proxy的路由轉寄規則。 |
管理唯讀節點流量 | Proxy會即時探測唯讀節點的狀態,當出現下述情況時,Proxy會執行流量管控動作:
|
緩衝熱點Key資訊 | 開啟代理查詢快取功能(Proxy Query Cache)後,Proxy會緩衝熱點Key對應的請求和返回資訊,當在有效時間內收到同樣的請求時直接返回結果至用戶端,無需和後端的資料分區互動,可更好地改善對熱點Key的發起大量讀請求導致的訪問傾斜。更多資訊,請參見通過Proxy Query Cache最佳化熱點Key問題。 說明 僅Tair記憶體型、持久記憶體型執行個體支援該功能。 |
支援多資料庫(DB) | 叢集模式下,原生Redis和Cluster client均不支援多資料庫(DB)功能,只使用預設的 說明 若您使用StackExchange.Redis用戶端,請使用StackExchange.Redis 2.7.20及以上版本,否則會產生報錯,更多資訊請參見StackExchange.Redis升級公告。 |
由於Proxy的演化,Proxy的個數並不完全代表Proxy處理能力,阿里雲會保證叢集規格中Proxy的配比符合規格說明的要求。
Proxy的路由轉寄規則
關於各類命令的介紹,請參見命令概覽。
架構 | 轉寄規則 | 說明 |
叢集架構 | 基礎轉寄規則 |
|
特定命令轉寄規則 |
| |
讀寫分離架構 | 基礎轉寄規則 |
|
特定命令轉寄規則 |
|
串連數使用說明
通常情況下,Proxy通過與資料分區建立長串連來處理請求。當請求中包含以下命令時,Proxy會根據命令的處理需求在相應的資料分區上建立額外的串連,此時串連無法彙總,執行個體的最大串連數和每秒建立串連數都會受到資料節點單個分區的限制(單個分區的限制請參見具體的執行個體規格)。您需要合理使用下述命令,避免串連數超限。
代理模式下,Redis社區版執行個體每個資料分區的串連數上限為10,000,Tair(企業版)執行個體每個資料分區的串連數上限為30,000。
阻塞類命令:BRPOP、BRPOPLPUSH、BLPOP、BZPOPMAX、BZPOPMIN、BLMOVE、BLMPOP、BZMPOP。
事務類命令:MULTI、EXEC、WATCH。
MONITOR類命令:MONITOR、IMONITOR、RIMONITOR。
訂閱命令:SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE、SSUBSCRIBE、SUNSUBSCRIBE。
常見問題
Q:是否支援將只進行讀操作的Lua指令碼轉寄至唯讀節點嗎?
Q:代理(Proxy)模式和直連模式有什麼區別,推薦使用什麼模式?
A:推薦使用代理模式,介紹與區別如下:
代理模式:用戶端的請求由代理節點轉寄至資料分區,可享受代理節點帶來的負載平衡、讀寫分離、容錯移轉、代理查詢快取、長串連等特效能力。
直連模式:可通過直連地址繞過代理,直接存取後端的資料分區(類似串連原生Redis叢集)。相比代理模式,直連模式節約了通過代理處理請求的時間,可以在一定程度上提高Redis服務的響應速度。
Q:如果後端的某個資料分區出現異常,對資料讀寫有什麼影響?
A:資料分區均採用主備高可用架構,當主節點發生故障後,系統會自動進行主備切換保證服務高可用。在特別極端情境下某個資料分區出現異常後,對資料的影響及最佳化方案如下。
情境
影響與最佳化方案
影響:
用戶端通過4個串連發送4個請求,當資料分區2處於異常狀態時,僅有請求1(GET Key1可正常讀取到資料),其他請求會訪問到資料分區2會返回逾時。
最佳化方案:
降低多Key命令(例如MGET)的使用頻率,或降低一次請求中包含的Key的數量,避免因單個資料分區異常導致該請求全部返回失敗。
降低事務類命令的使用頻率或降低事務大小,避免因某個子事務失敗導致整個事務失敗。
影響:
用戶端通過1個串連分別發送2個請求,當資料分區2處於異常狀態時,請求2(GET Key2)將返回逾時,同時由於請求1(GET Key1)和請求2共用同一串連,導致請求1也無法正常返回。
最佳化方案:
避免或降低對pipeline的使用。
避免使用單串連的用戶端,推薦使用串連池的用戶端,例如用戶端程式串連教程(需設定合理的逾時時間和串連池大小)。