在云數據庫 Tair（兼容 Redis）集群架構和讀寫分離架構中，代理服務器（Proxy）承擔著路由轉發、負載均衡和故障轉移等職責，可以幫助您簡化客戶端的邏輯，同時支持多數據庫（DB）、緩存熱點數據等高級功能。通過了解Proxy的路由轉發規則和特定命令的處理方式，有助于您設計更高效的業務系統。
Proxy介紹
圖 1. 集群和讀寫分離架構圖
代理服務器（Proxy）是Redis實例中的一個組件（單節點架構），不會占用數據分片的資源，通過多個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的路由轉發規則
關于各類命令的介紹，請參見Redis命令概覽。
架構 | 轉發規則 | 說明 |
集群架構 | 基礎轉發規則 |
|
特定命令轉發規則 |
| |
讀寫分離架構 | 基礎轉發規則 |
|
特定命令轉發規則 |
|
連接數使用說明
通常情況下，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：如果您的實例為集群版-單副本，由于僅具有主節點，無法保障數據可用性和服務連續性。推薦選擇集群版-雙副本，數據分片均采用主備高可用架構，當主節點發生故障后，系統會自動進行主備切換保證服務高可用。在某些極端場景下某個數據分片出現異常后，對數據的影響及優化方案如下。
場景
影響與優化方案
圖 2. 多Key命令場景
影響：
客戶端通過4個連接發送4個請求，當數據分片2處于異常狀態時，僅有請求1（GET Key1可正常讀取到數據），其他請求會訪問到數據分片2會返回超時。
優化方案：
降低多Key命令（例如MGET）的使用頻率，或降低一次請求中包含的Key的數量，避免因單個數據分片異常導致該請求全部返回失敗。
降低事務類命令的使用頻率或降低事務大小，避免因某個子事務失敗導致整個事務失敗。
圖 3. 單連接場景
影響：
客戶端通過1個連接分別發送2個請求，當數據分片2處于異常狀態時，請求2（GET Key2）將返回超時，同時由于請求1（GET Key1）和請求2共用同一連接，導致請求1也無法正常返回。
優化方案：
避免或降低對pipeline的使用。
避免使用單連接的客戶端，推薦使用連接池的客戶端，例如客戶端程序連接Redis（需設置合理的超時時間和連接池大小）。